Fred,

Right. What precipitated this was an attempt to retrieve some data from a SQL server here. Around 62,500 records. Took way longer than I had expected and it got me to thinking that there might be something I was overlooking or perhaps there were some "tweaking" secrets that others might have discovered.

One record plus some child records isn't a big deal but when I need to do some heavy-duty number crunching, at the rate I'm going, I'm going to have to resort to a backend COM or SQL-based OLAP or other process or get creamed. <g>

Best,

DD



>>Hey,
>>
>>Ok.. Given ODBC, ADO, and all the various methods of extracting data from a SQL 7.0 backend, what have you determined to be the "optimal" method.
>>
>>Given..
>>
>>1. A SQL 7.0 back end
>>2. A VFP front end (as an aside have you found Delphi or VB faster?)
>>3. Anything else inbetween to make things faster
>>
>>How do you deal with #3? Seems to me there are several paths here and I was just wondering where everyone landed.
>>
>>For example, do you use Intersolv's ODBC drivers or Microsoft's or ??'s
>>
>>Best,
>>
>>DD
>
>INHO
>
>We use nameless ODBC (M$ drivers) connections to connect to the database. All selects, updates, inserts, deletes (data Manipulation) are stored in SQL Stored Procedures. We use SQL pass through to pass only the minimal amount of information/data to SQL Server and let the server process the data. We do this for a very light weight frontend and minimal network traffic. Only the user interface is on the client side so the majority of changes/bug fixes occur on the backend and occur realtime. It would be no big deal to rebuild the front-end in any other (inferior) RAD tool. SQL Server must reside on a good box in this setup.