Problem with lock record (dbf/cdx)

[wartiaga]

Hi,

I have this code:

oArqUlt:GoTop()
Do While ! oArqUlt:RecLock()
MsgBeep()
MsgAlert("Record Lock!","Error")
Loop
Enddo
oArqUlt:Load()
oARQMAN:NUMERO := "LI"+Strzero(oArqUlt:PROXMFT,9,0)
oArqUlt:PROXMFT := oArqUlt:PROXMFT + 1
oArqUlt:Save()
oArqUlt:Commit()
oArqUlt:RecUnlock()

I use the ARQULT table to store the number of the next record to be inserted into another table, but it is happening that 2 people are using the same code, resulting in a duplicate record in the table that uses this field. What could be wrong?

Thanks in advance

[nageswaragunupudi]

resulting in a duplicate record in the table

The best way to avoid duplicates in a multi-user environment is to use AutoIncrement field. ( FieldType "+" )
Example:
Field ID in fwh\samples\customer.dbf
While adding a record, we should not assign any value to this AutoInc field ID.
Next value is automatically assigned by the RDD.

[wartiaga]

resulting in a duplicate record in the table

The best way to avoid duplicates in a multi-user environment is to use AutoIncrement field. ( FieldType "+" )
Example:
Field ID in fwh\samples\customer.dbf
While adding a record, we should not assign any value to this AutoInc field ID.
Next value is automatically assigned by the RDD.

Thank you Nages but the field needs to be composed of 2 other characters. Shouldn't RecLock() and RecUnLock() work?

[karinha]

Friend, mostre mais detalhes:

https://fivewin.com.br/index.php?/topic/41051-problema-com-lock-de-registro-em-rede-dbfcdx/

Regards, saludos.

[nageswaragunupudi]

Shouldn't RecLock() and RecUnLock() work?

Should work and we can make it work.
But this approach slows down performance when we add more and more concurrent users.
AutoInc field does not hit performance.

the field needs to be composed of 2 other characters

You are using TDatabase and this makes it possible in several ways.
Before I provide some samples, please let me know how those two prefix chars are decided? Does the user enter them?

[Rick Lipkin]

To All

In this crazy world of data hacks and database injection ... I ( myself ) prefer to lock a record with code ... update a value and then unlock .. Database injection is easy to infiltrate any table if you have an auto-increment field .... Just something to think about.

Rick Lipkin

[paquitohm]

Hola,

Aparentemente su codigo es correcto más alla de que no uso TDatabase y asimilo que funciona como las primitivas en las que se basa.

M he topado algunas veces con "choques" de "contadores". En mi caso no ocurren mucho y achaco que ocurran muy pocas veces a que mis clientes usan remote desktop

La bufferizacion que Windows introdujo, al menos desde la aparicion de SMB, rompio mucho codigo basado en tablas No--SQL. Una opcion de solucion puede ser inhabilitar los sistemas SMB de Windows

A pesar de que el problema se me ha dado pocas veces, hace años empecé a tomar la cautela de que cuando un registro se da de alta, se compruebe previamente si existe ya uno con ese codigo o número de "contador", asi aseguro la no duplicidad. Si por alguna razón existiera, pues mensaje interno o externo y da nuevo contador.

Salu2

[wartiaga]

Shouldn't RecLock() and RecUnLock() work?

Should work and we can make it work.
But this approach slows down performance when we add more and more concurrent users.
AutoInc field does not hit performance.

the field needs to be composed of 2 other characters

You are using TDatabase and this makes it possible in several ways.
Before I provide some samples, please let me know how those two prefix chars are decided? Does the user enter them?

Thanks you Nages!

he prefix is ​​chosen by the system operator, there are 2 types LI and LT I didn't include the entire code so as not to extend it too much.

[wartiaga]

Hola,

Aparentemente su codigo es correcto más alla de que no uso TDatabase y asimilo que funciona como las primitivas en las que se basa.

M he topado algunas veces con "choques" de "contadores". En mi caso no ocurren mucho y achaco que ocurran muy pocas veces a que mis clientes usan remote desktop

La bufferizacion que Windows introdujo, al menos desde la aparicion de SMB, rompio mucho codigo basado en tablas No--SQL. Una opcion de solucion puede ser inhabilitar los sistemas SMB de Windows

A pesar de que el problema se me ha dado pocas veces, hace años empecé a tomar la cautela de que cuando un registro se da de alta, se compruebe previamente si existe ya uno con ese codigo o número de "contador", asi aseguro la no duplicidad. Si por alguna razón existiera, pues mensaje interno o externo y da nuevo contador.

Salu2

Gracias por responder, esto también me ocurre en el mismo escenario, remote desktop. La idea de comprobar si ya existe antes de insertar los datos es válida, la usaré. Salu2

[wartiaga]

To All

In this crazy world of data hacks and database injection ... I ( myself ) prefer to lock a record with code ... update a value and then unlock .. Database injection is easy to infiltrate any table if you have an auto-increment field .... Just something to think about.

Rick Lipkin

Very important information, thanks!