Problem with lock record (dbf/cdx)

Problem with lock record (dbf/cdx)

Postby wartiaga » Sat Jun 15, 2024 1:15 am

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
wartiaga
 
Posts: 212
Joined: Wed May 25, 2016 1:04 am

Re: Problem with lock record (dbf/cdx)

Postby nageswaragunupudi » Sat Jun 15, 2024 3:52 am

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.
Regards

G. N. Rao.
Hyderabad, India
User avatar
nageswaragunupudi
 
Posts: 10690
Joined: Sun Nov 19, 2006 5:22 am
Location: India

Re: Problem with lock record (dbf/cdx)

Postby wartiaga » Sat Jun 15, 2024 12:24 pm

nageswaragunupudi wrote:
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?
wartiaga
 
Posts: 212
Joined: Wed May 25, 2016 1:04 am

Re: Problem with lock record (dbf/cdx)

Postby karinha » Sat Jun 15, 2024 2:13 pm

João Santos - São Paulo - Brasil - Phone: +55(11)95150-7341
User avatar
karinha
 
Posts: 7872
Joined: Tue Dec 20, 2005 7:36 pm
Location: São Paulo - Brasil

Re: Problem with lock record (dbf/cdx)

Postby nageswaragunupudi » Sat Jun 15, 2024 3:25 pm

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?
Regards

G. N. Rao.
Hyderabad, India
User avatar
nageswaragunupudi
 
Posts: 10690
Joined: Sun Nov 19, 2006 5:22 am
Location: India

Re: Problem with lock record (dbf/cdx)

Postby Rick Lipkin » Sat Jun 15, 2024 6:39 pm

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
User avatar
Rick Lipkin
 
Posts: 2666
Joined: Fri Oct 07, 2005 1:50 pm
Location: Columbia, South Carolina USA

Re: Problem with lock record (dbf/cdx)

Postby paquitohm » Sun Jun 16, 2024 9:28 am

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
paquitohm
 
Posts: 281
Joined: Fri Jan 14, 2022 8:37 am

Re: Problem with lock record (dbf/cdx)

Postby wartiaga » Sun Jun 16, 2024 1:06 pm

nageswaragunupudi wrote:
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
 
Posts: 212
Joined: Wed May 25, 2016 1:04 am

Re: Problem with lock record (dbf/cdx)

Postby wartiaga » Sun Jun 16, 2024 1:18 pm

paquitohm wrote: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
 
Posts: 212
Joined: Wed May 25, 2016 1:04 am

Re: Problem with lock record (dbf/cdx)

Postby wartiaga » Sun Jun 16, 2024 1:19 pm

Rick Lipkin wrote: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!
wartiaga
 
Posts: 212
Joined: Wed May 25, 2016 1:04 am


Return to FiveWin for Harbour/xHarbour

Who is online

Users browsing this forum: No registered users and 84 guests