While it's nice Koean points to a thread I explain SQLExpress, and this translates to SQL Server in many aspects - just another connection string and you can recycle the idea of SQLExec(). While that honors me, it's not what I would recommend in case of being able to use usual ways of working on data.
The way to get from a remote backend to the same cursor/workarea behavior you have on a USEd DBF file is what all remote data access variants have in common, you query remote data into a workarea and then can make use of CURSORSETPROP statements to make that updatable and then work on it just like working on a DBF with buffering, finally submitting buffered changes with TABLEUPDATE().
SQLExec created results can be turned updatable that way, remote views are closer in a way, as they incorporate the cursorsetprops in their definition (can even be seen as code in the view designer, if you switch to "View SQL", albeit in the form of DBSetProp instead of cursorsetprop, as it's permanent settings of views and not just temporary workarea, but look up cursorsetprop and dbsetprop and you'll see an overlap in the aspects of defining the properties necessary to update data, also as it works for DBFs with data access via local views.
And that is the limitation, too, you can forget to simply USE a remote table and have access to all records, you rather have to do it the way local views are meant to be used, first query the portion of data to modify, if only needing to add new rows that simply means querying a view with WHERE .F. (or for remote backends, which don't know VFPs boolean literal types WHERE 1=0), so you get an empty result and cann add to that and submit the new data with TABLEUPDATE().
That's the way to act on remote data in short. Before you get there it's a lot of details. In fact you could read part of the VFP help about views (local and remote), that's the root topic about all you need and you can add cursoradapter as a special way of "remote views" that offer some more things and are an oop way of using views, albeit it's mainly about their SelectCmd also being an SQL query just like the query you write or interactively create for views. There is no cursoradapter designer like the visual view designer, but you don't need to "handcraft" the SelectCmd of a cursoradapter class, you can create a class based on cursoradapter and right click and pick "builder" from the context menu to get to a simple designer. Once you defined the connection properties on the first "prpperties" tab, the "Build" buttons on the "data access" tab will get active and give a simplified query designer, in fact just the field selection portion of the view designer. But you may first create a normal view and then copy over the SQL from there to the cursoradapter.
Details. I could go on, bit then this will become a book. Fortunately a book like that also exists,
It's older, I guess it doesn't contain cursoradapter and it's written for an old version of SQL Server, but the mechanics is still the same.
Yes, there could be done a simple demo form fir same sample database provided as bak backup file you can restore and get this going, but no, it's no good idea of learning this or working with this and just changing table and field names. You have to learn a new way of acting on data and also forget a few things you can do with DBFs.
So I guess no one here will be willing to chunk out such an example form for you, it doesn't really help.
Start reading about views, as said, about buffering data, about data access for shared access and for remote access, you finally will learn also about ways even intended for DBFs and pardon me, if you already knwo about these you will see how the remote data access just is an add on to that technique and you can reuse code to use cursoradapters instead of tables in data environments, REQUERY them like the cursors of them where view cursors, TABLEUPDATE() or TABLEREVERT() them just like they were views or DBFa and even use transactions, albeit via sending BEGIN TRANSACTION and COMMIT to the server instead of simply doing it in VFP code.
Again, details. You only get this going through this, there is no shortcut, especially if you never even used buffering and client/server techniques on DBFs that's now a steep learning curve you avoided all the time it was already available to you without a remote backend to learn about, too.
Bye, Olaf.
Olaf Doschke Software Engineering
BC