How to read an database table step by step (with ADO)
-
Hi, I have to transport a big database table and can't read it at once with "select * from table" because the table is bigger than my system memory. Is there a way to read the table step by step? I thought it was possible with ADO and his serverside cursors but I don't now how. I need an "universal" solution that works on SQL Server 2000/2005, MySQL and Oracle. Regards, hairy
-
Hi, I have to transport a big database table and can't read it at once with "select * from table" because the table is bigger than my system memory. Is there a way to read the table step by step? I thought it was possible with ADO and his serverside cursors but I don't now how. I need an "universal" solution that works on SQL Server 2000/2005, MySQL and Oracle. Regards, hairy
Hello, ROW_NUMBER(), PARTITION BY may be used for this...btw why you want multiple times I/O solution when you can do it in one...and why you are worrying about the system memory its what OS is there for...am still not convinced of your idea! Regards, Adeel
Do rate the reply, if it helps or even if it doesnot, because it helps the members to know, what solved the issue. Thanks.
-
Hi, I have to transport a big database table and can't read it at once with "select * from table" because the table is bigger than my system memory. Is there a way to read the table step by step? I thought it was possible with ADO and his serverside cursors but I don't now how. I need an "universal" solution that works on SQL Server 2000/2005, MySQL and Oracle. Regards, hairy
Adeel is right - your ? is not well formed. Memory is the least of your problems. Disk IO, network latency and trafic volumes will play a larger role in your issue. If you have a large table/database to "transport" I suggest you investigate other transport methods other than read it into a UI and write it into another database. One method which will probably be faster is to BCP the table in/out of the databases. Each database type has different methods available, I suppose the UI path may be valid if you are looking for a DB agnostic solution. I suggest some furhter research, try asking for recommendations of moving table/s xxx big between db1, db2 and db3 you might get some enlightment.
Never underestimate the power of human stupidity RAH