Couldn’t perform the Edit because Another user changed the record

Asked

Viewed 1,038 times

6

Does anyone know if there is any trace of a table that is dropped from a bank? To make it easier if it’s recreated, for example, and when I say vestige is in the bowels of the bank itself.

I’m going through that famous 'Couldn’t perform the Edit problem because Another user changed the record. ' in an SQL connection with BDE/Delphi, the programming part in Delphi has already been done everything to avoid the problem.

Now, create a new table with another name, but with the same structure and with the data of the table that has the field that presents the error, which in this case is a FLOAT, the new table does not present the error.

Following this process, if I delete the table that presented the error, and recreate it with the same name taking the structure of the new table that had created and passing on the data also from this table, the error happens again.

That is, the problem only happens when I create the table with the name in which the error was first presented. The only suspicion I have left was that the bank keeps some information about the table that was dropped, and when it is recreated, it edits its data in some way, which makes it present the error.

  • Why do you need to recreate the table? The Post should work without generating any errors. How is this field in the database and how Delphi mapped it?

  • Did you try to change updateMode to upWhereKeyOnly? This should solve the problem without the need to recreate the table

  • Tried to switch from Requestlive to Cachedupdates? In addition to increasing performance, it could also solve the problem.

  • When you say that everything was done in Delphi to ensure the operation you mean that these two changes have already been made?

  • That’s right, it’s been a while since I’ve had the problem, and for new cases, I made the same changes you mentioned in Delphi and the problem stopped happening. But for the cases that presented the problem before the changes in Delphi, even if you use the corrected version, the problem keeps happening.

  • The field is FLOAT in the bank, and even without instantiating using SELECT * or instantiating as FLOAT in Delphi the problem happens. I started to recreate the table because I saw that a new one was created with the same structure, but with another name, the problem did not happen.

  • I do not understand, what are new cases and what are cases before the changes?

  • It’s my trip, the problem now, after I made the changes in Delphi, if you create a new table and write a float field with a tithe greater than 15 digits does not happen the error, if you use an old table, even dropping it, and recreating, the error happens.

  • @Robsonbraz, what is all you did to avoid the problem? Because with this statement you can induce colleagues and yourself to never find the error, since the problem may still be being generated by a programming error, when we use BDE to access files it is normal that these get corrupted, already tried to reinstall the BDE?

Show 4 more comments

1 answer

1

Actually the problem is with the BDE itself. Not with the database.

If the answer were only about the BDE, my recommendation would actually be to abandon the BDE and go to a preview mapping of less problematic data, such as Freedac, for example. Or SDAC (paid), or ADO (already comes with Delphi), if you have the patience to adapt the code and order the parameters in the order in which they appear.

After that little recommendation, let’s go to the answer.

This problem occurs with some things. In general, to solve, do the following, I suppose a structure with a TDataSetProvider and a TClientDataset:

DatasetProvider.UpdateMode = upWhereKeyOnly;
ClientDataSet.ProviderFlags = [pfInUpdate];

In the key field of TClientDataSet define the ProviderFlags = [pfInUpdate, pfInWhere, pfInKey].

Also remove the ProviderFlags of all other fields.

  • I’ve already made these changes to Delphi, and I can’t help but use the BDE, the system is too big. The problem now I believe is in the bank yes, because if you create a new table and write a float field with a tithe greater than 15 digits does not happen the error, if you use an old table, even dropping it, and recreating, the error happens.

  • @Robsonbraz The SDAC has a technology migrator. You don’t have to do anything: just run the migrator and it changes all the references of the BDE objects for you. In my systems, to avoid this kind of problem, I used BCD instead of Float.

  • 1

    @Gypsy omorrisonmendez BCD does not support more than 4 houses.

  • @It’s true, but I don’t know if his application is more scientific or financial. For the latter, BCD is better.

  • @Ciganomorrisonmendez Agree

  • @Robsonbraz Who must be caching something must be the BDE, the bank is not the culprit here.

  • 1

    @Robsonbraz View this table of yours under another name and test it with the view to see if it works or not.

Show 2 more comments

Browser other questions tagged

You are not signed in. Login or sign up in order to post.