Hi, Michael

My real-world experience with 'real' databases was extracting data for 
management reports from an Oracle database.  But I did learn a couple of 
things.

I assume the SQL database lives on its own server - most do.  In this 
case, you want to avoid dragging the whole thing down the LAN pipe if 
you don't have to.  So it may well pay to have a more complex Select 
that lets the server do the sifting and winnowing, pulling down only the 
data that's relevant to the task.

OTOH, cursors are one of VFP's great strengths, compared to other DB 
users.  If you have six related things to do, you may want to run two or 
three simple Selects, creating a mini-database of the result cursors, 
then run around in that.

In general, getting data from the (server) Database is slower than using 
the result cursor after you've got it, so I'd tend to minimize the total 
number of (real) SQL Selects and use VFP's local powers as much as possible.

Also, if you're not the DB Admin, watch out for configuration changes. 
I had my daily Select go from 10 seconds to five minutes one Monday - 
turned out the DBA changed the indexing rules.  I ended up removing one 
of the Where clauses and filtering it in VFP.

Dan Covill



On 04/13/12 13:52, Michael Oke, II wrote:
> Thanks all. With that I was able to update the two tables that I needed to 
> but I have hit another stumbling block. Can I open and work on multiple 
> tables from within FoxPro by querying them one at a time? Or do I need to 
> pull the data in one join that gets me all the line items in one select?  I 
> think that it is just me wrapping my head around a different method of 
> accessing data that is slowing me down somewhat.

_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to