Subject | Out-of-memory problem |
---|---|
Author | Gary Jones |
Post date | 2003-08-13T12:37:41Z |
Hi,
I'm using Firebird 1.03 with Delphi 5 and am experiencing a
frustrating problem. Here's the situation:
(I know that tables wouldn't normally be used in the way described
below in a C/S environment, but I'd like to know what's going on.)
Table1 has these fields:
Componentcode, life (51 records)
Table2 has these fields:
Uprn,componentcode,duedate (1.1 million records)
Pseudocode of what I'm doing:
########################
table2.open;
table2.first;
while not table2.eof do
begin
// Run query to look up value of "life" field from table1
// using componentcode as the joining field.
// Assign value of duedate field in table2 based on value
of "life".
table2.next
end;
########################
Table2 has no filters set and the only index that is the primary
key, which does not include duedate (the field being changed).
The application gets through around 600,000 of the 1.1 million
records in table2, then falls over with an "out of memory" error.
Watching the application processes in Windows Task Manager while the
application runs gives no indication that the application is using
anything like all the PC's available memory.
Any clues what's going on? Thanks.
Gary
I'm using Firebird 1.03 with Delphi 5 and am experiencing a
frustrating problem. Here's the situation:
(I know that tables wouldn't normally be used in the way described
below in a C/S environment, but I'd like to know what's going on.)
Table1 has these fields:
Componentcode, life (51 records)
Table2 has these fields:
Uprn,componentcode,duedate (1.1 million records)
Pseudocode of what I'm doing:
########################
table2.open;
table2.first;
while not table2.eof do
begin
// Run query to look up value of "life" field from table1
// using componentcode as the joining field.
// Assign value of duedate field in table2 based on value
of "life".
table2.next
end;
########################
Table2 has no filters set and the only index that is the primary
key, which does not include duedate (the field being changed).
The application gets through around 600,000 of the 1.1 million
records in table2, then falls over with an "out of memory" error.
Watching the application processes in Windows Task Manager while the
application runs gives no indication that the application is using
anything like all the PC's available memory.
Any clues what's going on? Thanks.
Gary