none
Error message: "there is not enough memory to complete this operation" in TABLEUPDATE in VFP9

    Question

  • I have a transaction with a lot of tables, one of these tables has about 7 million records (total size about 800 MB). I use optimistic table buffering. Everything in the transaction goes fine until I issue the TABLEUPDATE(2,.T.,lctable,vecerr). There appears the above mentioned error. Any idea how to fix this?

    WP

    Tuesday, March 05, 2013 7:06 PM

Answers

  • Hope your configuration allows to use more than 20 megs. What shows the SYS(3050)? You could try to increase the available buffer memory.

    If you update many different tables after BEGIN TRANSACTION (suppose all tables are transactable) then you may (or you even must) issue ROLLBACK command to return everything to the initial state. No table/row buffering and no TableUpdate is necessary in such case. Did you observe some orphans in your tables after rollback?

    Still valid is the rule: You should update as low number of tables as possible in one transaction.

    Tuesday, March 05, 2013 10:21 PM
    Moderator
  • Hello, possibly this file FPT with damaged records. Try copying the records into a new table or use a utility like CMREPAIR to correct the table.

    Edson


    Wednesday, March 06, 2013 12:31 AM

All replies

  • VFP has some limits...

    Table buffering uses memory buffers, transactions use memory buffers, the DBF data can use memory buffers... and FoxPro has approx 1.5 GB available at most.

    Did you check the memory consumed by VFP process in the Task Manager?

    OK. You would like to know what could help...

    First of all clear the memory cahce by SYS(1104)

    Second, don't use table buffering together with transactions. It just duplicates your data in two different memory buffers.

    Third, split your update operations into several smaller "chunks" executed in separate transactions or even without transactions.

    FoxPro can process 800 MB tables having 7 mio records but you should not process all these records at once (which I believe you don't do) or together with many other tables which can result in available memory resources shortening. Simple REPLACE command without buffering on the 800 MB table will work without problems.

    Tuesday, March 05, 2013 8:29 PM
    Moderator
  • Thanks Pavel,

    I have checked in the task manager that my vfp9.exe is consuming at most 20 MB of memory.

    I have tried putting  "=SYS(1104)" at the beginning of my program, the error message still appears.

    You suggest not to use table buffering together with transactions. But since my form updates many different tables, how can I guarantee without table buffering in the case of an error that everything is rolled back, and that there will be no widows and orphans in my tables?


    WP

    Tuesday, March 05, 2013 9:27 PM
  • Hope your configuration allows to use more than 20 megs. What shows the SYS(3050)? You could try to increase the available buffer memory.

    If you update many different tables after BEGIN TRANSACTION (suppose all tables are transactable) then you may (or you even must) issue ROLLBACK command to return everything to the initial state. No table/row buffering and no TableUpdate is necessary in such case. Did you observe some orphans in your tables after rollback?

    Still valid is the rule: You should update as low number of tables as possible in one transaction.

    Tuesday, March 05, 2013 10:21 PM
    Moderator
  • Hello, possibly this file FPT with damaged records. Try copying the records into a new table or use a utility like CMREPAIR to correct the table.

    Edson


    Wednesday, March 06, 2013 12:31 AM