Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

VFP ODBC Problem

Status
Not open for further replies.

IForgot

Programmer
Joined
Mar 20, 2002
Messages
122
Location
US
Here is a sacrilegious question. I have been a long time FP programmer and, for business reasons, have had to start adding VB to my resume.

I am working on converting a FPW application to the Visual world and need help with ODBC. I am figuring that you, as VFP gurus, have lots of experience with this issue and might consider helping me.

I can connect to the FP tables (free tables) and retrieve the appropriate records with an SQL Statement via the ADODBC.Connect, ADODBC.Open, ADODBC.Execute process into a Recordset.

But now, instead of bringing the data into a recordset, I want to immediately write it out to a new, temporary table for subsequent processing.

In FP the SQL statement is EASY and it works as expected.
SELECT <whatever> FROM <tables> INTO TABLE <result>

BUT when I use a string like that in my ADODBC SQL string, while it executes without error, no new table is created.

Can someone shed some light on what is wrong (aside from my working in VB instead of VFP).

Any assistance/suggestions you can provide will be greatly appreciated.

Thanks,
I_Forgot
 
Well first of all ado does not create foxpro cursors. The cursor is put into a recordset. Even though you cannot see it with the 'set' command in FP. You can browse the recordset using the adodbc.recordset object values. I did the same thing when I started using VB. You think life is simple in VB? Not as far as data manipulation. Of course there is the speed difference also. But you already know this.
 
This is the reason ADO sucks!!!

ADO has no native table format Like foxpro, SQL Server Access, or Orcale

anytime you want to do anything you need to create another ADO object, then take the new ADO object point it your other ADO object then you can run your new Select statment. but anytime you wnat to manipulat data chances are you will have 2 or more ADO objects running.


BTW: ADO.NET is a complete rewrite from the previous version and it only runs in the .NET framework, and much harder to use
 
Thanks for your response.

I am still left with the problem of specifically how to approach the problem of getting data from two separate SQL statement executions and bringing the data together. Note: it cannot be done with a single JOIN or other single SQL execution.

To: robsutonjr From your statement &quot;I did the same thing when I started using VB&quot;, it seems as though you have struggled through the same transition that I am attempting now. I'd appreciate learning more on how you approached some of the FP to VB transition issues like this and others if you would care to share your experiences.

Thanks,
I_Forgot
DhugalMac@Yahoo.com
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top