🚀 go-pugleaf

On Thu, 12 Aug 1999 17:55:15 +0200, "PIQUOT J�r�me" <wolff@media-net.fr>
wrote:

>when i apply updates from TClientDataSet i have an exception raised with
>this msg:"Record modified by another user".
>Could someone help to resolve this?

First of all,  are you positive that no one else is modifying your data
while your program is running?

Having said that,  I have recently responded to several people with the
same (or similar) error messages.  One thing to consider is that performing
equality tests on floating point values is not a wise thing to do.  Realize
that Date/Time, Currency, and such fields are often stored as floating
point values on many of the current database formats,  so using any fields
of that type on an equality test for an update may result in the error you
are getting if the field suffers from a "rounding error".  Some people can
solve this by changing their default UpdateMode to something other than
upWhereAll,  but that may not help you is the field you are changing is one
of the fields suffering from the rounding error,  or if it is a key field
(depending upon your choice for the UpdateMode)...

Jerry Bloomfield (TeamB)
-- 
Jerry Bloomfield                                     JersWork@wwa.com
Proud Member of Borland's TeamB
"We'll do anything if you don't pay us."

thanks for your reply but i do not perform equlity test. this exception
happens while i call Provider ApplyUpdates.
after the BeforeUpdateRecord event so i cant trace where it happens.

my app is a brief-case multi-tier client/server app  (the server is a MTS
dll) where CDS has data from a (TQuery) QueryCommande that has a detail
table (TTable) TableArticleCommande.

I use TableCommande (TJTableCommande inherited from TTable) to create Key
IDs. it uses the same table that QueryCommande but it is closed after use.

void __fastcall TIAMTSCommande::ProviderCommandeBeforeUpdateRecord(
   TObject *Sender, TDataSet *SourceDS, TClientDataSet *DeltaDS,
   TUpdateKind UpdateKind, bool &Applied)
{
 if (UpdateKind == ukInsert)
 {
  TableCommande->Active = true;
  TField *sfld, *dfld;
  TableCommande->SetKey();
  for (int i=0; i < TableCommande->IndexFieldCount; i++)
  {
   sfld = TableCommande->IndexFields[i];
   dfld = DeltaDS->FindField(sfld->FieldName);
   if (dfld)
    sfld->Value = dfld->Value;
  }
  if (TableCommande->GotoKey())
  {
   TableCommande->Edit();
   TField *sfld, *dfld;
   for (int i=0; i < TableCommande->FieldCount; i++)
   {
    sfld = TableCommande->Fields->Fields[i];
    if (!sfld->ReadOnly)
    {
     dfld = DeltaDS->FindField(sfld->FieldName);
     if (dfld)
      sfld->Value = dfld->Value;
    }
   }
   TableCommande->Post();
  }
  else
  {
   TableCommande->Active = false;
   throw Exception ("Commande non trouv�e");
  }
  Applied = true;
  TableCommande->Active = false;
 }
}

void __fastcall TIAMTSCommande::ProviderCommandeUpdateData(TObject *Sender,
TClientDataSet *DataSet)
{
 TableCommande->Active = true;
 TField *sfld, *dfld;
 int nFields = TableCommande->FieldCount;
 DataSet->First();
 while (!DataSet->Eof)
 {
  if (DataSet->UpdateStatus() == usInserted &&
DataSet->FieldByName("Code")->AsInteger <= 0)
  {
   try{
   TableCommande->Insert();
   for (int i=0; i < nFields; i++)
   {
    sfld = TableCommande->Fields->Fields[i];
    if (!sfld->ReadOnly)
    {
     dfld = DataSet->FindField(sfld->FieldName);
     if (dfld)
      sfld->Value = dfld->Value;
    }
   }
   TableCommande->Post();
   DataSet->Edit();
   DataSet->FieldByName("Code")->Value =
TableCommande->FieldByName("Code")->Value;
   DataSet->Post();}
   catch(...){}
  }
  DataSet->Next();
 }
 TableCommande->Active = false;
}
//--------------------------------------------------------------------------
-


--

-----------------------------------------------------------------
PIQUOT J�r�me
A. WOLFF SA
6, rue de la Gare
67120 ERNOLSHEIM/BRUCHE
FRANCE
e-mail: wolff@media-net.fr
http://www.media-net.fr/wolff
-----------------------------------------------------------------
Jerry Bloomfield (TeamB) <JersWork@wwa.com> a �crit dans le message :
37ba957d.458483384@forums.inprise.com...
> On Thu, 12 Aug 1999 17:55:15 +0200, "PIQUOT J�r�me" <wolff@media-net.fr>
> wrote:
>
> >when i apply updates from TClientDataSet i have an exception raised with
> >this msg:"Record modified by another user".
> >Could someone help to resolve this?
>
> First of all,  are you positive that no one else is modifying your data
> while your program is running?
>
> Having said that,  I have recently responded to several people with the
> same (or similar) error messages.  One thing to consider is that
performing
> equality tests on floating point values is not a wise thing to do.
Realize
> that Date/Time, Currency, and such fields are often stored as floating
> point values on many of the current database formats,  so using any fields
> of that type on an equality test for an update may result in the error you
> are getting if the field suffers from a "rounding error".  Some people can
> solve this by changing their default UpdateMode to something other than
> upWhereAll,  but that may not help you is the field you are changing is
one
> of the fields suffering from the rounding error,  or if it is a key field
> (depending upon your choice for the UpdateMode)...
>
> Jerry Bloomfield (TeamB)
> --
> Jerry Bloomfield                                     JersWork@wwa.com
> Proud Member of Borland's TeamB
> "We'll do anything if you don't pay us."

On Fri, 13 Aug 1999 10:27:00 +0200, "PIQUOT J�r�me" <wolff@media-net.fr>
wrote:

>thanks for your reply but i do not perform equlity test. this exception
>happens while i call Provider ApplyUpdates.

Well,  depending on how you have your UpdateMode set,  you may be
performing an equality test that you do not realize you are.  If you have
the UpdateMode set to upWhereAll,  you will perform an equality test on
every field in the record...  By setting the UpdateMode to upWhereKey,  it
will perform the equality test on the key fields only,  and upWhereChanged
will only compare against the fields which were changed.  

For most instances,  upWhereKey is sufficient when your table has a unique
index or key field.  upWhereAll is overkill in those cases,  as the
key/index field guarantee uniqueness.  I am sure there is a valid reason
for upWhereChanged,  but I can not think of one right now... :)

If your table has a unique key/index,  and you do not use any of the field
types I mentioned earlier (Date/Time, Currency, Float, Double, etc) then
you can set the UpdateMode to upWhereKey and quite probably resolve your
problem...

Jerry Bloomfield (TeamB)
-- 
Jerry Bloomfield                                     JersWork@wwa.com
Proud Member of Borland's TeamB
"We'll do anything if you don't pay us."

thanks for your answer.



--

-----------------------------------------------------------------
PIQUOT J�r�me
A. WOLFF SA
6, rue de la Gare
67120 ERNOLSHEIM/BRUCHE
FRANCE
e-mail: wolff@media-net.fr
http://www.media-net.fr/wolff
-----------------------------------------------------------------
Jerry Bloomfield (TeamB) <JersWork@wwa.com> a �crit dans le message :
37b8db76.541932617@forums.inprise.com...
> On Fri, 13 Aug 1999 10:27:00 +0200, "PIQUOT J�r�me" <wolff@media-net.fr>
> wrote:
>
> >thanks for your reply but i do not perform equlity test. this exception
> >happens while i call Provider ApplyUpdates.
>
> Well,  depending on how you have your UpdateMode set,  you may be
> performing an equality test that you do not realize you are.  If you have
> the UpdateMode set to upWhereAll,  you will perform an equality test on
> every field in the record...  By setting the UpdateMode to upWhereKey,  it
> will perform the equality test on the key fields only,  and upWhereChanged
> will only compare against the fields which were changed.
>
> For most instances,  upWhereKey is sufficient when your table has a unique
> index or key field.  upWhereAll is overkill in those cases,  as the
> key/index field guarantee uniqueness.  I am sure there is a valid reason
> for upWhereChanged,  but I can not think of one right now... :)
>
> If your table has a unique key/index,  and you do not use any of the field
> types I mentioned earlier (Date/Time, Currency, Float, Double, etc) then
> you can set the UpdateMode to upWhereKey and quite probably resolve your
> problem...
>
> Jerry Bloomfield (TeamB)
> --
> Jerry Bloomfield                                     JersWork@wwa.com
> Proud Member of Borland's TeamB
> "We'll do anything if you don't pay us."

If concurrency is not an issue for you. For instance, if you know no
one but yourself will be editing the records you are editing, then
what you can do is change the UpdateMode from UpWhereAll to
UpWhereKeyOnly. As long as your primary key is not a floating point or
datetime field (hidden floating point), then you will be okay.
UpWhereChanged in not usually a lot of help. It has the potential to
decrease the odds you will have the edit error, but it does not solve
the problem. UpWhereChanged can decrease the complexity of the WHERE
clause in the SQL statement that is generated, but in order to know
what changed, the BDE still must perform an internal comparison. If
this comparison contains floating point values, then the possibility
exists the rouding error will take place there, inside the bowels of
the BDE (which is the most likely place for the error).

On the other hand, if you and someone else perform concurrent edits on
these same records, you need another solution. UpWhereKeyOnly will not
help you because you need UpWhereChanged so you will be notified the
record was actually changed by someone else while you were editing it
yourself.

Matt Jacobs



--

My reply-to address is purposely mangled to thwart auto-reply bots. 
Please remove the two leading underscores if you wish to reply via
e-mail.

On Tue, 17 Aug 1999 09:50:26 +0200, "PIQUOT J�r�me" <wolff@media-net.fr>
wrote:

>thanks for your answer.

Were you able to resolve your problem with the information,  or does it
still persist for you?

Jerry Bloomfield (TeamB)
-- 
Jerry Bloomfield                                     JersWork@wwa.com
Proud Member of Borland's TeamB
"We'll do anything if you don't pay us."

yes thanks

--

-----------------------------------------------------------------
PIQUOT J�r�me
A. WOLFF SA
6, rue de la Gare
67120 ERNOLSHEIM/BRUCHE
FRANCE
e-mail: wolff@media-net.fr
http://www.media-net.fr/wolff
-----------------------------------------------------------------
Jerry Bloomfield (TeamB) <JersWork@wwa.com> a �crit dans le message :
37c01e8b.886725343@forums.inprise.com...
> On Tue, 17 Aug 1999 09:50:26 +0200, "PIQUOT J�r�me" <wolff@media-net.fr>
> wrote:
>
> >thanks for your answer.
>
> Were you able to resolve your problem with the information,  or does it
> still persist for you?
>
> Jerry Bloomfield (TeamB)
> --
> Jerry Bloomfield                                     JersWork@wwa.com
> Proud Member of Borland's TeamB
> "We'll do anything if you don't pay us."

I will use the Provider BeforeUpdateRecord to handle this. thanks

--

-----------------------------------------------------------------
PIQUOT J�r�me
A. WOLFF SA
6, rue de la Gare
67120 ERNOLSHEIM/BRUCHE
FRANCE
e-mail: wolff@media-net.fr
http://www.media-net.fr/wolff
-----------------------------------------------------------------
Matt Jacobs <mattja@ix.netcom.com> a �crit dans le message :
7pd65r$jr8@forums.borland.com...
> If concurrency is not an issue for you. For instance, if you know no
> one but yourself will be editing the records you are editing, then
> what you can do is change the UpdateMode from UpWhereAll to
> UpWhereKeyOnly. As long as your primary key is not a floating point or
> datetime field (hidden floating point), then you will be okay.
> UpWhereChanged in not usually a lot of help. It has the potential to
> decrease the odds you will have the edit error, but it does not solve
> the problem. UpWhereChanged can decrease the complexity of the WHERE
> clause in the SQL statement that is generated, but in order to know
> what changed, the BDE still must perform an internal comparison. If
> this comparison contains floating point values, then the possibility
> exists the rouding error will take place there, inside the bowels of
> the BDE (which is the most likely place for the error).
>
> On the other hand, if you and someone else perform concurrent edits on
> these same records, you need another solution. UpWhereKeyOnly will not
> help you because you need UpWhereChanged so you will be notified the
> record was actually changed by someone else while you were editing it
> yourself.
>
> Matt Jacobs
>
>
>
> --
>
> My reply-to address is purposely mangled to thwart auto-reply bots.
> Please remove the two leading underscores if you wish to reply via
> e-mail.
>