RE: [Dev-C++] RE: ODBC for free tables (Was: SQL "SELECT COUNT(*)" loads whole table into memory)

[Santiago P. C. <San...@yd...>]

Hi Ed,

I don't want to be rude with these words, but the answer is quite
simple: use a different ODBC driver (if possible).

As you have written in your post "the ODBC driver loads the whole table
into RAM", this behavior seems to be a problem/feature of the driver, so
there is nothing you can do from your app.

OTOH, you can try some other driver or dbmgr in order to achieve this...

Sorry for bringing you these bad news :o(

Regards,
~Santy

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Ed
Cottrell
Sent: domingo, 04 de enero de 2004 01:22
To: dev...@li...
Subject: [Dev-C++] RE: ODBC for free tables (Was: SQL "SELECT COUNT(*)"
loads whole table into memory)


Hi all,

I'm going to try rephrasing my question. If I'm using an ODBC driver to
connect to a Visual FoxPro (.dbf) data file, can I run queries without
loading the whole file into memory? For example, if I just want to count
records in a table, I would run the query "SELECT COUNT(*) FROM
[c:\somefile.dbf]", but the ODBC driver loads the whole table into RAM
to figure this out. How can I do this better?=20

Thanks for any help.

-Ed



-----Original Message-----
Sent: Friday, January 02, 2004 2:00 AM
To: dev...@li...
Subject: [Dev-C++] SQL "SELECT COUNT(*)" loads whole table into memory


Hi all,

Not technically a Dev-Cpp question, but I'm hoping somebody can help,
anyway. I'm working with an ODBC driver for Visual FoxPro 6 (as well as
ODBC drivers for several other RDBMSs). My application is supposed to
loop through a list of tables, run the single SQL statement "SELECT
COUNT(*) FROM tblname", get the result, then move on. At the end, I go
back and tally all the row counts.

In the process, I am simply reusing all my handles (environment,
connections, and recordsets), calling SQLGetData and SQLCloseCursor
after each query.

Now, here's the problem: even though I'm just doing SELECT COUNT(*), the
entire table is getting loaded into memory. My application's memory
usage goes from 6 MB to 100 +, though if I comment out just the FoxPro
database interaction, it stays around 8 MB, where I would expect it to
be. The logic and coding I'm doing for the FoxPro queries is absolutely
identical to the logic I'm using on the other databases, except, of
course, for the connection string, and I'm not having this problem with
the other systems. I should also point out that removing some of the
larger tables from the list of tables to check results in an almost
perfectly corresponding drop in RAM usage.

For what it's worth, doing the same query directly from Visual FoxPro 6
results in a RAM spike under 1 KB.

Anybody know what's wrong? Is there a driver setting I need to use or
something?

Thanks!

-Ed




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's Free Linux Tutorials.  Learn everything from the bash shell to sys
admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id371&op=3Dick
_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
-------------------------------------------------------------------------=
-------------
This message and any files transmitted with it are confidential and inten=
ded solely=20
for the use of the individual or entity to whom they are addressed. No co=
nfidentiality=20
or privilege is waived or lost by any wrong transmission.=20
If you have received this message in error, please immediately destroy it=
=20and kindly=20
notify the sender by reply email.
You must not, directly or indirectly, use, disclose, distribute, print, o=
r copy any=20
part of this message if you are not the intended recipient. Opinions, con=
clusions and=20
other information in this message that do not relate to the official busi=
ness of=20
Ydilo Advanced Voice Solutions, S.A. shall be understood as neither given=
=20nor endorsed by it.=20
-------------------------------------------------------------------------=
-------------