Hello Leland,

>It provided a stable platform. It was interesting that the grid columns bound into the MSSQL tables fields, so that any input made to the grid immediately updated the table. I wasn't use to this sync behavior and was more comfortable using an async method to connect to a backend serve whether two tier or three tier were used.

The architecture we advocate uses SQL Pass-Through to call stored procs to pull data from the server into VFP cursors. Data updates (Inserts, Updates, and Deletes) use ADO command objects to call stored procs and pass in the parameters. All data gets and mods are handled via stored procs. We don't use ADO recordsets in VFP apps.

SET BLATANT MARKETING ON

Those familair with it know that I just described how our DataClas/VFP middle-tier data component class works. < g >

SET BLATANT MARKETING OFF

>I found MS SQL to be somewhat slower in this two tier configuration when compared to native Visual FoxPro. I also found ADO OLEDB to be much more ackward than working with native tables.

That's because working with data as an object is different that working with native VFP cursors, though we do use native VFP cursors to work with child records of a parent record pulled down from the server. Allows use to continue to use the native VFP grid.

>I suppose I could have used a traditional wizstyle grid and grabbed recordsets from the backend and converted them to a cursor which could be used as the record source for the traditional grid,

Just use SPT to pull down records into a native VFP cursor automatically.

>but I never got around to this; although, I did experiment with recordset to cursor conversions annd vise versa.

Totally unnecessary if you don't use ADO recordsets.

>The activeX grid was very simplistic with no methods and few properties in which to build business logic or to validate input.

I wouldn't use that grid anyway. For our VB apps we use True DB Grid which is a VERY cool grid indeed.

>My evaluation indicate a significant re-write of my current file share applications would be necessary to make the application available under a MS SQL backend.

Yep.... the architecture of a file server application is different than a client/server application.

>I also installed MSDE, but at that time there was no way to administer it, except through the dos cmd window via SQL commands, unless I resorted to the GUI that installed with the full version of MSSQL.

MSDE is NOT intended to be installed on your development machine. It is intended to be shipped with your application. Think of it as the runtime SQL Server data engine.

>I have also worked with mSQL, MySQL, and Postgres on Linux and Windows platforms using both a two tier and three tier approach.

Great, then you're familair with how database servers work.