• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 270
  • Last Modified:

Paradox tables repeatedly "reverting" on a local install

Hi all,

I have an application which is currently running on just one machine. I am running paradox tables using the BDE. On one table, it seems like after every third or fourth update, the data reverts to a previous state.

The application keeps track of totals of numbers and how they got that way, the 'total' record is updated from a 'charges' record. The next time a 'charge' is made, a new charges records is made and the 'totals' record is updated to reflect what the new total is.

Every so often, the database holding the totals goes back to a previous set of data, from 3, 4, or 5 sets of transactions ago.

I can see the behavior reflected in the data (the charge table keeps track of the total before and after it is updated) but I can't replicate the problem on my machine.

This may be a BDE setting problem, any suggestions? I am currently using posts on the records.

Leo
0
oneeye
Asked:
oneeye
  • 4
  • 3
  • 3
1 Solution
 
lottolCommented:
try to add after post next string:

 Table1.FlushBuffers;

where Table1 is your TTable object
0
 
adengCommented:
I don't really understand the procedure of updating the record that you're using, can you post your code here.... (but simplify it first)...

Regards
Adeng
0
 
oneeyeAuthor Commented:
Here is the chunk of code. I'm going to be rewriting it in SQL eventually, but the really odd thing is that it works fine on three machines, but the "ttable" periodically goes back three of four transactions, as I said in the initial problem statement.

   ttable.indexname := 'RankIndex';
   ttable.Edit;
   ttable.first;
   while not ttable.eof do
      begin
      {grab the keys here}
         if chgtable.FindKey([detkey,perkey,listkey]) then
            begin
               ttable.edit;
               if (ttable.fieldbyname('total').asinteger
                  <> chgtable.fieldbyname('newtotal').asinteger)
                  then begin
                     ttable.fieldbyname('datestamp').asdatetime := date;
                     ttable.fieldbyname('timestamp').asdatetime := time;
                  end;
               ttable.fieldbyname('total').asinteger
                  := chgtable.fieldbyname('newtotal').asinteger;
            end
         else ChgTable.insertrecord([1,detkey,perkey,listkey,ttemp,1,ttemp,rankkey]);
         ttable.post;
         chgtable.Edit;
         chgtable.fieldbyname('stamp').asfloat := now;
         filldetailform.ttable.next;
      end;
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
adengCommented:
here's the first problem :

  ttable.Edit;
  ttable.first;

If you put First procedure after edit then the record will be post..

in the "While not eof" loop, after,
  chgtable.edit;
  chgtable.fieldbyname('stamp').asfloat := now;

you did'nt put "chgtabel.POST"

I don't know here but this line :
  filldetailform.ttable.next;

what if you change it to
  ttable.next; (no filldetailform) ?

BTW, I think TQuery is better then TTable, .

Regards,

Adeng.



0
 
oneeyeAuthor Commented:
Yes, I quite agree, now that I have started using them. (Tqueries, that is) The stray form declaration happened because for a time, I was getting an unable to find table error.

I'll check to see if the chargetable's are posting properly.

Leo
0
 
lottolCommented:
As far, as I've worked with Paradox. It's better to use TTable, not TQuery, because Paradox isn't SQL DB. It just simulates it. Using TQuery takes much time and sometimes it doesn't work correctly.
0
 
adengCommented:
You right about that, but in the case of using windows, TQuery is quit stable than TTable. when using TTable and windows, the table crash quite often (index out of date, etc.)
0
 
lottolCommented:
"Index out of date" happens mostly in those situations, when you copy table "on fly" or don't use exclusive mode for updating records in tables, which are accessed by many users.
I can say that it's impossible to wait queries, if you have multiple users, besides Paradox isn't the best DB for multiple users. :)
0
 
oneeyeAuthor Commented:
Adenq:

Thanks for the tips on the code, I'll mark it as answered, though in the interim I tracked my problem to another piece of code altogether, heh.

I've been converting this application from using filtered tables to Tquery for the past week or so. The speed difference isn't all that visible on my 2 gig machine, but boy it is obvious on the 300 mhz pIII one of the applications is installed on. Opening up a filtered table takes a 10 count using TTable, it is less than a second opening the same table using a Tquery.

Using Ttable, I kept getting index out of date about once every 3 months, often enough that I wrote a small application to fix it when it happened. If that problem goes away with using mostly read only Tqueries, that will make me very happy.

Leo
0
 
adengCommented:
Dear Leo,

Nevermind, nice to help you solve the problem. My project using more than 100 table, very complex logic and more than 4 year in the market, and get no problem very much with paradox table.

Best Regards
Adeng
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 4
  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now