>Thanks for feedback all.
>
>Yes I think it the bug rearing it's head, which is troublesome as it contains data that could be of any length.
>
>What would be the best way of achieving the same outcome of creating a connection without using SQLStringConnect? Apologies for the level of questions, this is a whole new area for me.

You could create and register a file dsn programmatically - the directory where it goes is, at least on my machine, "c:\Program Files\Common Files\ODBC\Data Sources", and the file format is a simple .ini type... something like

[ODBC]
DRIVER=SQL Server
UID=your username, though unnecessary with trusted_connection
Trusted_Connection=Yes
DATABASE=db name here
WSID=your machine name here, not really necessary
APP=any string here
SERVER=(local)
Description=...

So it's basically your connect string split into lines at semicolons, with the [ODBC] section header. You can create such a file from your connect string in a single line of VFP code.

You also need to register this in odbc.ini, which would require two entries there (not sure why), one to add your dsn to the list, and the other to say which odbc driver does it use. That should be in the Windows directory, and any WritePrivateProfileString routine should be capable of that. Just create one FileDsn manually and see what it does in both locations. The name of this entry should be equal to juststem(your .dsn file).

Then you should be able to use the SqlConnect(odbcName). Haven't tried this, not sure whether these ini entries are enough, or does it require some messing with the registry.