>>>Ultimately I'd like to be able to do the SQL Server query within the VFP app directly but I don't have any experience using VFP and SQL Server. I'm probably the only person that still does anything in our IT department with FP/VFP. We have people that do that kind of thing in VB but I'd rather stick with VFP. I have access to the VB code used to get the data I can use as a starting point. If anyone has some articles I could read on how to do SQL Server (I think it's SQL Server 2000) queries with VFP I'd love to read them. I have used SQL queries on native FPW tables a lot but I haven't used any of the SQL features added in VFP 6.
>>>
>>>Any help would be greatly appreciated.
>>
>>Larry,
>>Check strconv(), filetostr(),strtofile().
>>SQLServer queries are not hard.
>>ie:
>>

>>lnHandle=SQLStringConnect('DRIVER=SQL Server;SERVER=servernamehere;'+;
   'DATABASE=pubs;Trusted_Connection=Yes')
>>SQLExec(lnHandle, "select * from employee", 'myEmployee')
>>SQLDisconnect(lnHandle)
>>
>>select myEmployee
>>browse
>>

>>Cetin
>
>The VB code that is used apparently uses something called "Microsoft ActiveX Data Object 2.5 Library". Is there a way for my VFP app to use this or something like it? I'd like to avoid having to add an ODBC DSN on each machine that uses my app.

Larry,
Yes you can :) You could either use that activex or simply use its code version too. Before sampling that note that with above code you don't need to add any ODBC DSN on any machine. It's DSNless connection. IOW it's string based and you can define, alter the definition anytime. For a starter I'd suggest you to use Remote View (RV) instead. VFP use command was enhanced to include 'CONNSTRING' clause. With that you could open your view with a different connection string (DSNless connection).

ADO connection. This is what "Microsoft ActiveX Data Object 2.5 Library" is about. It comes in 2 versions, as an activex control and totally programmatic version. Since activex version is nonvisual at run time I prefer code version (in VB it's not nonvisual) which doesn't also need a container. ADO itself is a huge subject even it has a a separate help file.
ADO uses OLEDB and SPT (SQL Pass Through - SQLExec), RV use ODBC.
To keep it short lets connect, update and exit SQL server's sample pubs database (my SQL server installation for pubs is on server 'cetin\cetin' and I use both a 'windows authentication' and 'SQL server authentication' - mixed. Integrated Security=SSPI (or Trusted_Connection=Yes) causes to use my windows authentication. Therefore no UID and PWD attributes here.) :

#Define SQLCONNECTION 	"Provider=SQLOLEDB.1;Integrated Security=SSPI;"+;
  "Persist Security Info=False;"+;
  "Initial Catalog=Pubs; Data Source=cetin\cetin"

Local oRecordSet As ADODB.Recordset, oConnection As ADODB.Connection

oRecordSet = Createobject("adodb.recordset")
oConnection = Createobject("adodb.connection")

With oConnection
  .ConnectionString = SQLCONNECTION
  .Mode = 16  && adModeShareDenyNone
  .Open()
Endwith
With oRecordSet
  .ActiveConnection = oConnection
  .LockType= 4  && adLockBatchOptimistic
  .CursorLocation= 3  && adUseClient
  .CursorType= 2  && adOpenDynamic
  .Source = 'select * from Titles'
  .Open

*Let's show what we have got
*HFlex activex grid is one we could use to 'browse'

  ShowMe('Contents of Titles Before Update',oRecordSet)

*Now we'll increase price by 1$ where type = 'psychology'
* PS: This is one way of doing it, not the only way.
  .Filter = "type = 'psychology'"
*First let's check again this set before update
  ShowMe('Filtered Contents of Titles Before Update',oRecordSet)

*OK now let's increase the prices and update
  .MoveFirst
  Do While !.Eof
    .Fields('price').Value = .Fields('price').Value + 1
    .MoveNext && skip:)
  Enddo
  .UpdateBatch() && TableUpdate(.t.)
*And check updated set
  .Requery() && Requery to be sure we're seeing updated content
Endwith
ShowMe('Filtered Contents of Titles After Update',oRecordSet)

Function ShowMe
Lparameters tcCaption,toRecordset
oForm = Createobject('myForm', tcCaption,toRecordset)
oForm.Show
Read Events
Endfunc

Define Class myform As Form
  Height = 450
  Width = 750
  Name = "Form1"

  Add Object hflex As OleControl With ;
    Top = 10, Left = 10, Height = 430, Width = 730, Name = "Hflex", ;
    OleClass = 'MSHierarchicalFlexGridLib.MSHFlexGrid'

  Procedure Init
  Lparameters tcCaption,toRecordset
  This.Caption = tcCaption
  This.hflex.Datasource = toRecordset
Endproc
  Procedure QueryUnload
  Clear Events
Endproc
Enddefine

Now let's do the same with SPT (this time decreasing prices by 1$ that we just increased) :

#Define SQLCONNECTION 	"Driver=SQL Server;Integrated Security=SSPI;"+;
  "Database=Pubs; Server=cetin\cetin"
Local lnHandle
lnHandle = SQLSTRINGCONNECT(SQLCONNECTION)
SQLEXEC(lnHandle,'select * from Titles','crsTitles')
*Let's show what we have got
BROWSE TITLE 'Contents of Titles Before Update'
*Now we'll decrease price by 1$ where type = 'psychology'
*First let's check again this set before update
SQLEXEC(lnHandle,"select * from Titles where type = 'psychology'",'crsTitles')
BROWSE TITLE 'Filtered Contents of Titles Before Update'
*OK now let's decrease the prices and update
SQLEXEC(lnHandle,"update Titles set price = price - 1 " +;
        " where type = 'psychology'")
*Check what we've done
SQLEXEC(lnHandle,"select * from Titles "+;
        " where type = 'psychology'",'crsTitles')
* We're done disconnect
SQLDisconnect(lnHandle)
BROWSE TITLE 'Filtered Contents of Titles After Update'

Remember these are samples and only one way of doing it. However I must admit for myself SPT version is much more easier to handle with VFP controls/commands/functions. ie: It takes only a few lines of additional code to promote the cursor you got from SQL server with 'select ...' to an updatable cursor. You could simply use that cursor if it were a VFP table in your forms :) With ADO it's much more tricky (and up to date I didn't see a solid reason to use ADO over SPT except few special cases - there are some benchmarks on foxvikis.com that you might check).
With SPT you could not only query/update SQL server but even manage it - like adding/removing users, their rights, database/table/storedproc/triggers creation/modification etc :) RV looks like VFP 'builder/designer' version of SPT (just a rough comparison - SPT has power of control). Though not as powerfull as SPT on the things you can do with it, RV is easier. VFP writes and manages code for you :)

Plenty of code :) However you'd like to hear above sample codes are much simplier in VFP8 through CursorAdapter and you could directly work with controls/commands/functions you know well (and ADO.NET sets as well).

PS: I later noticed VFP6 in your message. Remove 'as ...' part in local declarations and you'd be still well. No VFP7-8 specific code.

On MSDN help try to read 'ADO jumpstart for VFP developers' by JVP. However honestly today (meaning .NET and ADO.NET is around and also VFP8) I suspect you have need to learn ADO. Instead it'd be better to follow 'Client/Server' section of UT and read SPT/RV on VFP help.
Cetin