If your custom application can access user DSNs, you should be able to pass it the following connection string.

DSN=SOTAMAS90;UID=user;PWD=password;Company=ABC;

If it can't access user DSNs then you can always have it create a system DSN by writing to the registry but this would require elevated rights. You would just copy the contents of the user DSN to the system DSN so the paths are correct. You can then optionally set specific options for your system DSN. 

If you don't want to use "DSN=" in your connection string, you could instead use "driver={MAS 90 4.0 ODBC Driver}" followed by all the required parameters. I prefer using the DSN route since i won't have to worry about paths. As long as the workstation is updated during the upgrades or server moves, the user DSN named SOTAMAS90 should always have the correct paths and default options.

Your best and really only option is to create a silent DSN. Plenty of post on how to create one. What you are seeing with the SOTAMAS90 DSN is working as designed. No way to change.  

Thank you for the suggestion.  Unfortunately, we have tried the formats you're suggesting without success.  We've tried both "DSN=SOTAMAS90;UID=user;PWD=password;Company=ABC;" as well as "DSN=SOTAMAS90SILENT;UID=user;PWD=password;Company=ABC;" (using a silent connection we've set up), but despite supplying all needed credentials in with the connection string MAS is still prompting the user for credentials if they are not present in the ODBC control panel for the SOTAMAS90 DSN.  Even when using the second format mentioned that is pointing to a different DSN, it is still prompting for credentials (and stranger yet, even though we're specifying a different DSN when we supply SOTAMAS90 with credentials in the ODBC control panel the application runs without prompting the user).  It behaves as though the driver is hard-coded to use the SOTAMAS90 DSN when the driver is used regardless of the settings we provide.

I agree that the SOTAMAS90 DSN is working as intended.  We'd like to use the silent DSN we've created but even when defining the connection string to use our silent DSN it still behaves as though it's connecting to the SOTAMAS90 DSN

Is your application 64-bit?  Did you create a 64-bit silent DSN?

Refreshing this spreadsheet query does not prompt for credentials:

Get a working connection string that doesn't prompt (validated in Excel when you Refresh All), and use that.  Then if you get a prompt in your application you know it is not related to the string.

It is a 32bit application (written in VB6, actually).  To be certain, we did recently install the 64-bit driver in case the ODBC was trying to use that, but that didn't seem to make any difference in the behavior, either.

Hi You can try a DSN-Less ODBC Connection string

i.e.

Driver={MAS 90 4.0 ODBC Driver}; Company = ABC; UID=ALL; PWD='' Directory=C:\Sage\Sage 100 Standard\MAS90; LogFile=\PVXODBC.LOG; CacheSize=4; DirtyReads=1; BurstMode=1; StripTrailingSpaces=1; SERVER=NotTheServer

The SOTAMAS90 DSN should not be used for any third party ODBC access.  The DSN is recreated on each startup of Sage 100.

John Nichols

Sage

It's been some time since I've worked with VB6, but the following code snippet is what we used to use in our VB.NET apps when accessing Sage data..  It dynamically builds a connection string depending on if the install is Standard or Advanced (C/S).  

Perhaps, you can re-tool it to fit in VB6.

Dim constr As String = ""

If CBool(My.Settings.CS) Then
constr = constr & "DSN=SOTAMAS90; Directory="
constr = constr & My.Settings.SageInstall
constr = constr & "; Prefix="
constr = constr & My.Settings.SageInstall
constr = constr & "\SY\, "
constr = constr & My.Settings.SageInstall
constr = constr & "\==\; ViewDLL="
constr = constr & My.Settings.SageInstall
constr = constr & "\HOME; LogFile=\PVXODBC.LOG; RemotePVKIOHost="
constr = constr & My.Settings.SageServerName
constr = constr & "; RemotePVKIOPort="
constr = constr & My.Settings.SagePort
constr = constr & "; CacheSize=4; DirtyReads=1; BurstMode=1; StripTrailingSpaces=1; SERVER=NotTheServer"
constr = constr & ";UID=" & My.Settings.SageUserName & ";PWD=" & My.Settings.SagePassword & ";Company=" & CompanyCode
Else
constr = constr & "DSN=SOTAMAS90; Directory="
constr = constr & My.Settings.SageInstall
constr = constr & ";UID=" & My.Settings.SageUserName & ";PWD=" & My.Settings.SagePassword & ";Company=" & CompanyCode
End If

Dim con As System.Data.Odbc.OdbcConnection = New Data.Odbc.OdbcConnection(constr)

Thanks for the suggestion.  We've tried forgoing the DSN and using the driver specification previously, however when we had we had not included curly brackets around the driver name.  I should be able to give that a try later today

I am afraid that using the syntax with curly braces around the "Driver" variable did not resolve the issues we are seeing.