Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Losing data - serious problem
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00554460
Message ID:
00558197
Views:
17
Einar,

I would suggest using a special table that contains the next value for the ID number. This table could have a column for the table to be updated and the value to update with (name this field nextKey for example), just in case the application grows. Then create a function that gets a lock on this table, seeks the table name, stores the value to a variable, increments the value in the special table and then unlocks it. This way, you are not relying on the code looking at the last record in the main table. If the record pointer somehow gets moved, it becomes unreliable (this is just one possible cause). We use this method where I work and it is very dependable.

Dana

>Hi,
>I have a VFP 6.0 laboratory system for grain samples. Tha lab is collecting data about weight, water%, protein etc. It is quite simple with one main DBF. This DBF is FOX2x as I need to read data from another program. There are 10 PCs adding record and updating the file. The volume is about 1500 new samples every day added from 2 of the machines and 3-5 updates on these records from the other PCs. Input is mainly from bar-codes and online weights.
>
>Last monday and yesterday the DBF was truncated in some way. After the first incident I created local logging on each computer, so now I could pick up the missing pieces. Yesterday at 10:11 new records were added from ID 10316 and at 13:26 the new records were up to ID 12612. Then the next record is logged at 15:19 with ID 10316 again!!! (The next ID is picked from the last record+1)
>
>It is a multiuser system with record locking (3) storing data on a Windows NT 4.0 computer. The workstations are Windows NT 4.0.
>
>All appending happens in on place. When clicking New the program does:
> Append BLANK
> replace status with 'X'
> Unlock RECORD 0
> FLUSH
>
>The editing field has the table fields as recordsource. When clicking Save the program does:
>
> If TableUpdate(.T.,.T.)
> If EMPTY(makorn.kornid)
> Do WHILE !FLOCK('ma50')
> Messagebox('Can't save new ID')
> Enddo
> currec=recno()
> cOrder=Order()
> Set order to tag kornid
> Goto bottom && makorn
> nID= makorn.kornid+1
> Set order to tag (cOrder)
> Goto currec
> Replace kornid with nID, regdato with DATE()
> Tableupdate(.T.,.T.)
> Unlock
> Flush
> Unlock in MA50
> .oFrmLogg.Logg('Ny post') &&logg
> Endif
> Else
> Messagebox('Can't save new record')
> Tablerevert(.T.)
> Endif
> Unlock
> Flush
>
>I added the FLUSH after the first incident. One theory is that the PC adding records lost power and the record-counter was never saved. The system has been running daily for almost a month now.
>
>Can you help?
>
>
>Einar
Where's the damned Any Key?...too late
Previous
Reply
Map
View

Click here to load this message in the networking platform