Before You Install
Before inserting the CD in your computer, you should understand the following things about installing FBS 11.7:
- .NET Framework 4.7.2 will be installed on your computer if it is not already present.
- FBS 11.7 should be installed in a new folder that does not contain any previous FBS release.
- To avoid issues with software activation, FBS 11.7 detects an existing 8.16, 10.5, 11.1, 11.2, 11.3, 11.4 or 11.5 installation folder and copies some files from it.
- Different installation options are used for standalone, server, and workstation computers.
- In a multi-user installation, FBS 11.7 must be installed on every computer that runs FBS 11.7.
In a multi-user configuration using shared folders, FBS 11.7 should always be installed to the shared folder from the server, not from a workstation.
Installing In a New Folder
The default installation folder displayed by the installer for FBS 11.7 is "C:\FbsWin11.7" instead of "C:\FbsWin11". You don't have to use this folder, but the folder you do use should be empty.
If you reinstall FBS 11.7 without uninstalling it first, then this installer page does not appear and the installer uses the same installation folder as before.
Detecting a Previous Installation Folder
The installer checks for a previous installation of FBS 11.5, FBS 11.4, FBS 11.3, 11.2, 11.1, 8.16, or 10.5; in that order. If one is found then the previous install folder's location is displayed. The files that control configuration and activation will be copied from the previous installation.
If you have multiple FBS installations, you can select the install folder from which you want the installer to copy files. If you don't want to use any previous installation then you can select the current install folder, in which case no files will be copied. If you reinstall FBS 11.7 without uninstalling it first, then this installer page does not appear and no files are copied from the previous installation.
Copying the Data Folder
It is common, particularly for single user installations, for the data files to reside in a "DATA" folder under the installation folder. Since FBS 11.7 is installing in a new installation folder, the installer copies the contents of such an existing "DATA" folder to a new "DATA" folder under the new installation folder. If the data files are in any other folder then no copy is made, as the installer assumes you are managing the folder for the data files yourself. If you reinstall FBS 11.7 without uninstalling it first, the installer does not copy any files in any "DATA" folder.
Installation Options
There are three installation options in a drop down box on the installer's "Select Components" page:
Standalone Configuration - this option can be used for most installations because it allows the selection of individual components. It defaults to a full install, but unneeded modules can be unselected. This option should not be used on workstations in a multi-user system, as a local copy of FBS modules is unneccessary and leads to confusion and mistakes.
Network (File) Server Configuration - a preset option for installing on the file server in a shared folder, network configuration. This option is recommended for server installations.
Network Client (Workstation) Configuration - a preset option for installing on a workstation in a shared folder, network configuration. This is the option for workstation installations. No FBS modules are installed. Only FBS libraries, .NET Framework 4.7.2, and ActiveX controls are installed on the client.
Multi-user Installation
In a multi-user installation there is always a server computer on which the software is installed using the installer's Server Configuration option. The other computers are client (workstation) computers on which the software is installed using the installer's Client Configuration option. The Client Configuration option must be used for the client computers, the other installation options are not supported on a client computer.
A multi-user installation should be performed using the following steps in the given order.
FBS is installed on the server computer using the Server Configuration option. The software must be installed in a folder on one of the server's physical hard drives (commonly the 'C:' drive). The default folder is 'C:\FbsWin11.7'.
An additional storage folder should be created on one of the server's physical hard drives. The recommended storage folder is 'C:\FbsFiles', with each company's data files in 'C:\FbsFiles\DATA'. Many installations use the installation folder itself, 'C:\FbsWin11.7' as the storage folder. In this configuration, each company's data files are in 'C:\FbsWin11.7\DATA'. However this approach is less secure because the installation folder cannot be made read-only.
The installation folder must be shared. This can be done using the Windows file explorer, opening the properties window for the file, selecting the 'Share' tab and clicking on 'Advanced Sharing'.
Clicking on 'Permissions' in the 'Advanced Sharing' window will bring up a dialog box which can be used to control access to the shared folder. The default is to give 'Everyone' access, but for greater security access can be limited to specific accounts on the server. When a separate storage folder, like 'C:\FbsFiles', is used; the installation folder can be made read-only. This helps limits the spread of viruses in the local network.
If a separate storage folder is not used, then users must be given full control over the installation folder.   This is less secure because the client computers trust the programs in the installation folder and an infected client computer can modify them and spread the virus to the other client computers.
Regardless of the security permissions, all shared folders used by FBS must have caching disabled. Clicking on 'Caching' in the 'Advanced Sharing' window will bring up a dialog box which can be used to control caching for the shared folder. The 'No files or programs from the shared folder are available offline' option must be selected.
If a separate storage folder, like 'C:\FbsFiles', is used then it must be shared like the installation folder is shared. However users must always have full access to the storage folder because they create and update the files in it.
While not strictly necessary, it is a good idea to create a 'DATA' folder inside the storage folder. All of the data files can then kept in the 'DATA' folder, while files like 'fbsuser.mdb' can be kept above them in the storage folder itself.
Each shared folder must be mapped to a network drive on the client computers. This is done on the client computer by right clicking on the 'Computer' icon in Windows file explorer and selecting the 'Map Network Drive' option. All client computers must use the same drive letter for the network drive.
In a multi-user installation, the 'config.ini' file on the server must be updated. By default the 'config.ini' file reflects a standalone installation. The client and server value for 'CommonAppDataDir', 'DefaultDataDir', and 'EnterpriseDataDir' must be updated. If the storage folder on the server is 'C:\FbsFiles' and this folder is mapped to the 'H:' drive on the client computer, then the 'config.ini' file should be changed as follows:
FBS should be installed on a client computer only after it is installed on the server, the shared folders are created on the server, the shared folders are mapped to network drives on the client computer, and the config.ini file is updated on the server. FBS is installed on the client computer using the Client Configuration option.
FBS must be run on the client computer from the shared installation folder. An easy way to do this is to use a shortcut on the client desktop. This shortcut can be created by right clicking on the 'FbsMain.exe' program in the network folder, dragging it to the desktop, releasing the right mouse button, and selecting 'Create Shortcuts Here' from the popup menu.
Multi-Tenant Installation
A multi-tenant installation is an installation where multiple FBS customers share a single Windows Server. This type of installation is not supported by the FBS installer. If you need this kind of installation, please contact FBS for support.
Additional Considerations
Upgrading From FBS 11.1 or Earlier
FBS 11.4 uses the same multi-user password protection as FBS 11.2 and later releases. However the FBS 11.2 password enhancements were not fully backwards compatible with previous versions. Make sure you understand the differences so that you will be able to login after upgrading. The changes are described in the "Username / Password Changes" section.
Upgrading From FBS 8.16 or FBS 10.5
FBS 11.1 upgraded the 8.16 or 10.5 Jet 3.5 data files to Jet 4.0. FBS 11.7 has replaced the conversion utility with the FBS Database Upgrade wizard. The wizard will also convert Jet 3.5 data files to Jet 4.0 so upgrading from these versions is fully supported.
Upgrading From an 8.x Version Prior to 8.16
The FBS Database Upgrade wizard is not tested with versions earlier than 8.16. If you are on an earlier version of the 8.x series of releases then you should upgrade to version 8.16 before upgrading to version 11.7.
Upgrading From a 10.x Version Prior to 10.5
The FBS Database Upgrade wizard is not tested with versions earlier than 10.5. If you are on an earlier version of the 10.x series of releases then you should upgrade to version 10.5 before upgrading to version 11.7.
Installing on Windows Server 2008 SP2
The .Net Framework 4.7.2 is not available for Windows Vista or Windows Server 2008 SP2. FBS has discontinued support for these Windows versions.
New Features
Version 11.7
FBS 11.7 is the general release of the 11.6 code and includes the Fecher translation from Visual Basic 6 to .NET Framework 4.7.2 for most of TransAction Plus and Smart Feeder. The Fecher translation for Crop Audit reporting will be added in subsequent patches to FBS 11.7.
FBS 11.7 contains numerous improvements requested by MASA members using FBS 11.6.   These improvements were originally distributed as patches to FBS 11.6 and are now included in FBS 11.7.   The performance of TransAction Plus reports, Smart Feeder reports, the Commercial Feed Mill interface, and the Packer interface have been substantially improved.   In addition the load time for editing a Journal entry has been greatly reduced for large journals.
Version 11.6
FBS 11.6 is adds the Fecher translation from Visual Basic 6 to .NET Framework 4.7.2 for most of Smart Feeder. FBS 11.6 also contains improved check printing performance. Check printing has been rewritten to follow the current Windows 10 and .NET Framework printing guidance. FBS 11.6 is available to MASA members for production use, but it is envisioned as an early feature release, which is likely to require improvements.
Version 11.5
FBS 11.5 provides the first fruits of the Fecher translation from Visual Basic 6 to .NET Framework 4.7.2. Most of the TransAction Plus modules are now .NET Framework code instead of Visual Basic 6 code.
Version 11.4
FBS 11.4 provides the first fruits of the migration from Visual Basic 6 to .NET and the conversion of FBS binary files to SQL database tables. The FBS 11.4 release in conjunction with the following releases will move key Setup data into SQL database tables and provide .NET modules for maintaining the data.   The new SQL database tables will enable future enhancements to improve FBS reporting performance and flexibility and better integration of FBS data with other software.
.NET Setup Programs for Chemical, Fertilizer, Seed, etc.
FBS 11.4 provides the following new .NET modules for maintaining setup data.   The modules are identified by their entries on the FBS main menu.
- Setup -> Commodity Codes
- Setup -> Cost/Profit Centers
- Setup -> Crops -> Seed Traits
- Setup -> Crops -> Chemical Types
- Setup -> Crops -> Active Ingredients
- Setup -> Crops -> Field Operations
- Setup -> Crops -> Seeds
- Setup -> Crops -> Chemicals
- Setup -> Crops -> Fertilizers
- Setup -> Crops -> Storage Locations
- Setup -> Crops -> Fields
- Setup -> Crops -> Fuels
- Setup -> Crops -> Application Methods
Chemical, Fertilizer, Seed, etc. files Moved to SQL Tables
FBS 11.4 moves the following data from binary files into SQL tables. The FBS Database Upgrade program has been enhanced to perform the migration.
- Commodity
- Center
- Seed Traits
- Field Operation
- Seed
- Chemical
- Fertilizer
- Nutrient
- Bin (Storage Location)
- Field
- Fuel
- Trait
Version 11.3
FBS Database Upgrade
FBS 11.3 delivers a new FBS Database Upgrade Wizard. This wizard installs new ERP Resource and Supply tables. These tables will be used to migrate Crop Audit setup files like Chemicals and Seed from their current individual, binary files into database tables. The wizard also upgrades the LedgerSetup (Account) table, the VendorDetail table, and the TransAction Plus Header and Detail tables.
New Installation Script
FBS 11.3 uses a new install script which eliminates the requirement that FBS verions be installed over each other. The script detects exiting FBS installations and copies the necessary files to enable FBS 11.3 to work in a new folder. Installing FBS in a new folder is now the recommended method of installation.
"config.ini" File
FBS versions prior to 11.3 determined some configuration information every time the application started. An unintended side effect was that the application could start with an incorrect configuration if the environment changed. The FBS 11.3 installation script determines the configuration at install time and writes the information to the "config.ini" file. Future releases will take advantage of this to provide more configuration options and a simpler installation process.
Visual Basic 6.0 To .NET Migration
FBS 11.4 has many internal changes that are not visibile to FBS customers. The goal of these changes is to support the incremental replacement of Visual Basic 6.0 (VB6) with Microsoft's .NET Framework. The new .NET Framework code will provide a more modern user interface, improved reporting speed, new reporting functionality, integration with the Web, and increased reliability. For those that are interested, the next three sections provide an overview of changes.
COM Callable Wrappers
VB6 is based on an older Microsoft technology known as COM. To facilitate interoperation between VB6 and .NET, Microsoft provides tools for the development of COM callable wrappers for .NET code - https://docs.microsoft.com/en-us/dotnet/framework/interop/com-callable-wrapper.
FBS uses four COM callable wrappers for its .NET code. These are contained in the TaDeskComSvr.dll, CaDeskComSvr.dll, SbDeskComSvr.dll, and SfDeskComSvr.dll files. In FBS 11.4 all of the Crop Audit setup data is handled by .NET code in CaDeskComSvr.dll and the VB6 code has been modified to call it using COM.
Registration-Free COM Interoperation
COM normally requires information to be added to the Windows Registry for its operation. This would be a problem for FBS multi-user systems as Registry information and FBS code would have to be on every workstation and kept in sync. FBS 11.4 avoids this issue by using Microsoft's registration-free COM interoperation technology - https://docs.microsoft.com/en-us/dotnet/framework/interop/registration-free-com-interop. Every VB6 program has been modified to include embedded COM configuration information. In addition the COM callable wrappers also contain embedded COM configuration information. As long as all the files are in the same folder, COM interopation between VB6 and .NET works without using the Windows Registry.
Mixed (Native and .NET) Assemblies
Unfortunately some FBS VB6 code is shipped as Windows native DLLs. Functions in these DLLs are called by other VB6 code running in the Windows VB6 runtime; which is not the runtime for a native DLL. Two of these DLLs are CAEDIT3.DLL and CAEDIT5.DLL, and their functionality will be replaced by the .NET versions CaEdit3113.dll and CaEdit5113.dll. However the VB6 code in Windows VB6 runtime has no means of calling the .NET versions.
The solution is to provide a native DLL that VB6 code can call and to write that native DLL in a way that it can call the .NET DLL. This kind of DLL is known as a mixed (native and .NET) assembly; a DLL being one kind of an assembly. Microsoft provides tools for writing a mixed assembly - https://docs.microsoft.com/en-us/cpp/dotnet/mixed-native-and-managed-assemblies?view=vs-2017.
FBS 11.4 provides DLLs like CaEdit3Bridge.dll and CaEdit5Bridge.dll which are mixed assemblies. These mixed assemblies are called by VB6 code and they in turn call the corresponding .NET DLLs, CaEdit3113.dll and CaEdit5113.dll.
Version 11.2
Username / Password Changes
In version 11.2 the username and password are now case sensitive. The maximum length of the password has been increased from 8 to 250. In addition passwords are no longer stored in the FbsUser.mdb database (only the hash of the password is stored). These changes bring FBS into compliance with NIST recommendations for handling passwords, addressing some customer requirements.
Previous versions converted usernames and passwords to upper case for storage and comparison. When Version 11.2 converts this data, it changes the case to lower case. For example, if you were typing your username as “Joe”, earlier versions stored it as “JOE” and this version converts that to “joe”. So typing “Joe” will not match your converted username and you must type “joe”.
Likewise passwords were converted from uppercase to lower case before they were hashed and removed from the database. For example if your password was “1234Hi”, earlier versions stored it as “1234HI” and this version converted it to “1234hi” before hashing it and storing the hash. So typing “1234Hi” won’t match your converted password and you must type “1234hi”.
Additionally earlier versions of FBS accepted passwords with lengths greater than 8 characters, but only stored and compared the first 8 characters. For example, if your password was “1234OutTheDoor”, earlier versions stored it as “1234OUTT”. So in this version you must type “1234outt” to match your password.
Going forward, a new username of “John” will be stored as “John” and password of “AveryLONGmixedCASEpassword” must be typed exactly the same way to get a match.
Fix for Windows Server 2008, 2008 R2, 2012, and 2012 R2 File Corruption
This changes impacts Network (File) Server / Network Client (Workstation) configurations.
Since Microsoft introduced version 2.0 of the Server Message Block (SMB) protocol in Windows Server 2008, there has been a series of issues with SMB corrupting Access *.mdb (Jet 4.0) files. The following references cover some of the issues and workarounds.
https://support.microsoft.com/en-us/kb/2028965
https://support.microsoft.com/en-us/kb/2618096
https://support.microsoft.com/en-us/kb/2957623
http://tipsntricks.sherr.co.uk/stop-smb-corrupting-files/
FBS software is also negatively affected in other ways by SMB's caching of file data.
This release includes changes to the SMB configuration in the Windows Registry to address this issue by turning off SMB file caching. While this change lowers networking performance, it avoids the file corruption and instabilities which can be caused by SMB caching.
5.2 Disable Offline Availability for Shared Folders with FBS Programs or Data
As with SMB caching of file data, the Shared Folder feature for working offline can corrupt *.mdb files. When Shared Folders are used to share FBS programs or data between several computers, the offline available option should be "No file or programs from the share are available offline.". The following link provides documentation from Microsoft on how to set the caching options for a shared folder.
https://technet.microsoft.com/en-us/library/cc755136(v=ws.11).aspx
Version 11.1
Jet Drivers Are No Longer Installed
This release uses Jet 4.0 and converts existing *.mdb files to the newer Jet 4.0 *.mdb file format. Starting with Windows Vista, Microsoft has bundled the Jet 4.0 drivers with Windows. FBS uses the Windows Jet 4.0 drivers and no longer installs the Jet 3.5 drivers.
Supports Windows Known Folders
In Windows Server or Remote Desktop environments, Windows Known Folders can be redirected to different locations. FBS will automatically detect a Known Folder's current location during program startup.
Version 11 uses three Known Folders:
· Common AppData folder ("C:\ProgramData\FBS Systems") - contains the non-program files which were installed in the FBS program folder in earlier releases. It is also the new default location for the FBS data folder.
· AppData folder ("C:\Users\<username>\AppData\Roaming") - contains user specific configuration files, temporary files, and log files. These files are available to a user when they login to any PC in a Windows Server Domain.
· Local AppData folder ("C:\Users\<username>\AppData\Local") - contains user specific log files local to the PC.
New Default Configuration Which Splits Executable from Data Folders
Version 11 detects and uses the existing (single) folder configuration for existing installations. Only new installations will use the new default configuration.
For new installations, Version 11 defaults to a two folder configuration:
· "C:\FbsWin11" - which can be made a read-only shared folder for the FBS programs.
· "C:\ProgramData\FBS Systems" - which can be the shared folder for FBS configuration and data.
In a future release the installation location will change from "C:\FbsWin11" to "C:\Program Files\FBS Systems". For this release the default installation location is the same as the 8.x releases so that some optional program files can be detected and automatically upgraded to Version 11.
As part of UAC compliance, the default location of the FBS data folder has been moved from under the installation folder to the "C:\ProgramData\FBS Systems\DATA" folder.
The changes enable the FBS program folder to be made read-only to better protect a Server from virus infections on client PCs.