<< Click to Display Table of Contents >> Navigation: Admin Tool > Setup Tasks > Database Location |
By default, MIL-Comply uses a desktop database (Paradox) to store shipping and labeling data. This is generally sufficient for individual users when the database is resident on a local hard drive. MIL-Comply also works well with Microsoft SQL Server (MSSQL), which is recommended for multi-user environments. Using a shared Paradox database in such environments has the potential to result in productivity issues. MIL-Comply is compatible with all known versions of MSSQL (Professional, Enterprise, and Express).
This dialog allows the user to select between using a desktop database and MSSQL. It is found in the AdminTool, in Tools > Database Location.
Adding a Paradox database is as simple as creating a folder, then pointing the software at it using the [Set] button. MIL-Comply will create the needed tables. The folder should be accessible to all MIL-Comply users of a machine. It should not subject to OneDrive synchronization, which is not entirely compatible with Microsoft's ODBC driver for Paradox.
By default a Database sub-folder is created in the Application Data Folder, which when both are defaulted will be the C:\MilPac-AppData\Database folder. This was changed from the C:\ProgramData\Mil-Pac\Comply folder in Release 1.6.0244 to avoid the issue described next. Note that the database folder does not have to be in the Application Data Folder.
A common issue that occurs when the user first attempts to login to MIL-Comply is the report of a "-1" error creating or accessing the database. This is often the result of the folder being created during installation by someone of higher authority than the user. If that problem cannot be resolved, choosing a different folder is an alternative.
Sometimes a conflict exists between the Windows ODBC driver and its use of OneDrive synchronization. We recommend using a non-synchronized folder, which includes all folders with the User data tree. Another issue can be a permissions associated with a network drive. This error occurs typically in network domains with tight security policies. The software user should be the currently logged Windows user when the database is created, not a system administrator that might have installed the software. Sometimes access problems can only be solved by making the user a local administrator of the workstation.
There are two ways remedy this issue. The fastest approach is to get Local Admin privileges for your computer. Once you have those, you’ll be able to have full access to the software. Since allowing Local Administrator privileges may violate internal IT policies, the other approach is to migrate from the desktop database to a Microsoft SQL Server database - Enterprise, Standard, or Express (free version). Once you have a database environment established along with an user account, we can assist you with connecting MIL-Comply to SQL Server.
Moving an existing database to a new folder is fairly straightforward.
1.Create an accessible folder
2.Use the [Open] button to open the current database folder
3.Copy the files to the new folder
4.Remove any/all of these files: Paradox.NET, Paradox.LCK, PdoxUsrs.NET, PdoxUsrs.LCK
5. Using the [Set] button to identify the new folder
It is easy to use MIL-Comply with MSSQL server (Professional, Enterprise, or Express). We strongly encourage users sharing a common database to do so for the potential benefits in speed, reliability and capacity. (Requires a separate MIL-Comply license for each user.)
The process is fairly straightforward with existing MSSQL servers. Your database administrator simply creates a blank database and provides the access credentials. There is really nothing else the DBA needs to do, as MIL-Comply will automatically create the necessary tables.
A Data Source (DSN) will need to be created in the Windows ODBC Data Sources settings. The name of the DSN and the other fields listed in the Database Location dialog (above) are copied from the DSN into the fields in the dialog above. Note that the DSN must be the User type, using SQL Server Authentication. For more information refer to the MCA-SQLServerUpgrade PDF.
See also:
Removing Paradox Locks