>I've read a few posts here and I've got an issue I've seen reported previously where I believe you are unable to use a string which is greater than 254 characters in length with the command
>
>lnHandle = SQLStringconnect(lcStringOver254Characters)
>
>The issue I have right now is that users are able to configure their own DSN files in our software, by either using file DSN file or Machine DSN files. We store the information in a table to be used later; the SQL select (they can select only some of the fields from the data source, and also filter it) and also the connection string in a DBF.
>
>I read about how the SQLExec can be split into nice chunks to allow that to work and got that working great, and also fixed numerous problems with embedded quotes, spaces in alias names etc, however if the connection string is over 254 characters (which it commonly can be if people use longer filenames and locations), I get the 'string too long to fit' error.
>
>Am I able to use the TEXTMERGE workaround in this example? All I need is the handle of the connection and I'm away. I'm not sure on the options available to me. The design of the application is pretty much set in stone being a legacy system as this is an enhancement only. At the moment I'm having to warn that the DSN file information is too long, which looks pretty naff.

Is your lcStringOver254Characters really in a variable? If it's a literal, then it's VFP's limitation - any string literal can't be longer than 254. Just break it into "1st piece"+"2nd piece" etc, so you have two literals or more.

If it's in a variable already, then... tough.That'd mean it's the limitation of the SqlStringConnect(). I've never measured mine, and I know I never used literals. I store these in ini files, and they can be any length, but I figure I never had anything over 200.

If everything else fails, you may try to take out some unnecessary parts of the string, like app's ID, user/pass if you're already using trusted connection etc. See what's the minimal set that works.