In other words, you are proving my point that VFP does SQL Server just fine, no real benefit in that specific area with going to dotnet. Right?


>Randy
>
>With the new CONNSTRING clause for RVs we don't need ODBC DSNs on client pcs any more, or connections in the dbc.
>
>We've written a tiny app that allows users to specify database type (oracle, SQL Server etc), servername, database, usernamne, password. The app assembles a connection string and encrypts it into a .dat file. Then we have a truly *tiny* class that can be passed names of RVs or SPT as follows
>
>oRemote.USE([myRemoteViewName])
>oRemote.SQLExec([select * from mytable where fieldname=?lcfieldname],[cursor])
>
>The class whips the connectionstring out of the encrypted file and uses it appropriately.
>
>Because we no longer need to manage ODBC dsns or DBC connections for each customer, we now include a dbc with nothing but Views into our VFP executable, eliminating the reported contentions and slow opening of DBCs. And each client has and can maintain its site-specific connection settings securely and with ease.
>
>You won't believe how happy customers are to lose the #$%^#$T% ODBC DSN!
>
>This works really well with SQL Server.
>
>Regards
>
>JR