"Charles Tyson" <cmtNOSPAMzeebox@sbcglobal.net> wrote in message
news:E7F92ABF-518E-4717-98E6-84DCF043B404@news.elevatesoft.com...
> You might try inserting this statement after each RunSQL():
>
>     SetProcessWorkingSetSize( GetCurrentProcess, DWORD(-1) , DWORD(-1) );
> // or
> $FFFFFFFF, $FFFFFFFF
>
> This is supposed to force Windows to rethink how much RAM the application
> actually
> needs--it has the same effect as minimizing & maximizing the application.
> A lot of Delphi
> experts say that calling this procedure is useless window dressing
> (Windows ought to be
> taking care of low-memory situations on its own), but it doesn't seem to
> be dangerous or
> cost much execution time.
>

The issue is that if it is true that this is happening, it is potentially a
nasty error in DBISAM. Maybe someone should try to reproduce the problem.

Robert,

<<The issue is that if it is true that this is happening, it is potentially a
nasty error in DBISAM. Maybe someone should try to reproduce the problem.>>

I will try to prepare a small program which simulates the problem.  Whoever interested in this test can send me an email and I will reply to him/her
the test program.

Regards,
Abdulaziz Jasser

"Robert" <ngsemail2005withoutthis@yahoo.com.ar> wrote:

>The issue is that if it is true that this is happening, it is potentially a
>nasty error in DBISAM. Maybe someone should try to reproduce the problem.


I tried, but wasn't able to reproduce the problem (using D5 and 4.24b1 on XP).  I imported
a series of tables (DAT size on disk 6 to 25 MB)--Process Explorer showed that the memory
allocated for the INSERT was about 2x the combined DAT+IDX size, and was released when
each table was freed.  When the DAT file was 50 MB (950000 small records), the program
became "non-responding" but didn't cause an out of memory error.  I couldn't see any sign
of the memory allocations stacking on top of the last.  This was on a laptop with 512MB,
so perhaps a rule of thumb is that memory tables shouldn't be larger than 5% of RAM.

Abdulaziz


Post it to the binaries ng that way we call all have a look

Roy Lambert

Roy

<<Post it to the binaries ng that way we call all have a look >>

Done.  I've posted the code I am using.  I am sure it's not a DBISAM problem therefore the problem should comes from my code.  But I can not see
it.  Any way this code generates the problem if I run it against my database.  Hope this will explain my problem.

Regards,
Abdulaziz Jasser

Abdulaziz Jasser wrote:
> Done.  I've posted the code I am using.  I am sure it's not a DBISAM
> problem therefore the problem should comes from my code.  But I can not
> see
> it.  Any way this code generates the problem if I run it against my
> database.  Hope this will explain my problem.
>
You have put everything in one big transaction. Dbisam has to save all
changes so it can undo them if you rollback the transaction.

Bernd Kuhlmann

Abdulaziz,

<< Done.  I've posted the code I am using.  I am sure it's not a DBISAM
problem therefore the problem should comes from my code.  But I can not see
it.  Any way this code generates the problem if I run it against my
database.  Hope this will explain my problem. >>

Bernd is correct, you put the whole thing inside of a transaction, therefore
DBISAM will buffer all inserts until the transaction is committed or rolled
back.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<Bernd is correct, you put the whole thing inside of a transaction, therefore
DBISAM will buffer all inserts until the transaction is committed or rolled
back.>>

This was my first thing to be tested.  But the same problem is happing even without opening a transaction.  So I tested the same code in another PC
and still have the same problem.  I even went back to version 3.30 and still have the same thing (the original database was 3.30).  I also
run "Repair" from DBsys program to check for any corruption but also no luck.

Abdulaziz,

If you're sure the transaction isn't the cause...

1.  What version of Delphi are you using?  Patched to what level?
2.  What version of DBISAM are you using?
3.  What operating system?
4.  How much RAM?
5.  Are you running any program which might intercept file operations, e,g. Antivirus?
Version control?  Automatic backup?  Recycle bin recovery?  If so, turn them off and see
if the problem still remains.
6.  Are you using the standard Delphi memory manager, or something else?
7.  If you run only the UPDATE SQL statements, do you see the memory problem?
8.  If you run only the DELETE statements, do you see the problem?
9.  If you run only the INSERT statements, do you see the problem?
10.  What is the disk size of the files being INSERTed into memory (DAT + IDX)?  (Average,
and largest)
11.  If you run the full program using small input files, does it complete successfully?
12.  How are you measuring the memory usage?
13.  Has this procedure ever worked?  If yes, what has changed recently?
14.  What is the failure error message?  Is it coming from your code, Delphi, or Windows?

Charles

Charles,

<<1.  What version of Delphi are you using?  Patched to what level?>>
Delphi7 Enterprise with no patches.

<<2.  What version of DBISAM are you using?>>
3.30 & 4.24

<<3.  What operating system?>>
XP Pro.

<<4.  How much RAM?>>
1 GB

<<5.  Are you running any program which might intercept file operations, e,g. Antivirus?
Version control?  Automatic backup?  Recycle bin recovery?  If so, turn them off and see
if the problem still remains.>>
No

<<6.  Are you using the standard Delphi memory manager, or something else?>>
standard but I tried FastMM4 and did not help.

<<7.  If you run only the UPDATE SQL statements, do you see the memory problem?>>
No, only with INSERT.

<<8.  If you run only the DELETE statements, do you see the problem?>>
No

<<9.  If you run only the INSERT statements, do you see the problem?>>
YES

<<10.  What is the disk size of the files being INSERTed into memory (DAT + IDX)?  (Average,
and largest)>>
DAT=25 MGB IDX=25 MGB BLB=92 MGB

<<11.  If you run the full program using small input files, does it complete successfully?>>
Yes

<<12.  How are you measuring the memory usage?>>
By eatching Windows TaskList.

<<13.  Has this procedure ever worked?  If yes, what has changed recently?>>
Yes it was working with smaller data. We didn't modify this code for months.

<<14.  What is the failure error message?  Is it coming from your code, Delphi, or Windows?>>
It's a Delphi error.