Goldmine Connections using ADO/UDL Files

In order to fax to Goldmine contacts using the CopiaFacts workstation client, which is the equivalent of the OmniRush Universal Print Client, you must be able to connect to the Goldmine database using Microsoft Active Data Objects (ADO). The database connection parameters are specified in a Microsoft Universal Data Link (UDL) file. By default, the UDL file is created in the folder Default Client located in the FaxFacts\Userjobs folder in the CopiaFacts application data share, normally called Copia. The name of the UDL file is Goldmine Contacts.UDL. You may specify a unique UDL file in the Resources folder in the folder set for individual users under FaxFacts\Userjobs. This UDL file will take precedence for that user over the default UDL file.

When you double-click on this file it will open up the Microsoft Data Link Editor, which will display a window similar to the one below:

The dialog box entries may vary depending upon the provider. Generally, you will need to select the database to connect to and whether or not you will be using Windows NT integrated security, i.e., Windows authentication or a specific SQL user and password to connect to the database. Goldmine should normally be set up for mixed mode authentication, so either method will work. If you do decide to use a user name and password to connect to SQL Server, make sure you check the option Allow saving password. You will also need to specify the server name and SQL instance, which is separated from the server name by the backslash (\) character. When you have completed the entries correctly, you should be able to click on the Test Connection button and get a successful test message. You should be able to do this from each machine that has the CopiaFacts client installed.

If you cannot get a valid test connection, or if you double-click on the link file and get an error, you may not have the correct SQL provider on the machine you are running from. If that happens, create an empty text file on your local drive using Notepad, rename that file to Goldmine Contacts.UDL, and then double-click on the new file. When the Microsoft Data Link Editor opens the file, click on the Provider tab to display a list of providers that are installed on your machine. The dialog will look something like this:

The list contains all of the ADO providers installed on your machine. Ideally all client machines will have at least the same SQL providers installed and will be using the same ADO provider to connect to Goldmine. The most efficient ADO provider is currently the SQL Native Client provider. It is available for download at: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=228de03f-3b5a-428a-923f-58a033d316e1&DisplayLang=en

If you choose to use different SQL providers on different client machines, you will need to use separate Goldmine Contacts.UDL files for users who will be using those machines. You will have to select the provider and test the connection on the Connection tab. Once you have created a local Goldmine Contacts.UDL file and have tested the connection and gotten it working, you should copy it to the Resources folder for that user. The Resources folder is located in the FaxFacts\Userjobs\Username (where Username is the user’s Windows login name) in the Copia application data share folder. The user will then use that UDL file to connect to Goldmine rather than the common UDL file in the Default Client folder.

Sometimes the connection test may work and yet you will still be unable to connect to Goldmine from the CopiaFacts client. In that case, you will need to run FFTrace and make sure that FFClient is in the application list. The trace output should display the error message the client is getting from the provider. Examining this error message along with the SQL Server log should give you an idea about what the problem is. The problems are usually login problems having to do with security and permissions for a particular user that may need to be resolved by your DBA. If you are using Windows NT integrated security in the Connection tab, the problem might be resolved by switching to a specific SQL user account and password.