Data Shifting Between Records

?

"Ashley" wrote in message
...
hey, what's up.............................
"Neil" wrote in message
et...
Thanks for your reply, Gordon. But, unfortunately, there is no code that
updates these fields. They're simply bound controls, and are managed by
the control and the ODBC driver.

Furthermore, the fact that the contents of the control are replaced by
the content of a previously saved record in that control indicates that
it can't be user error. These controls hold multiple sentences. For the
user to be able to retype exactly what was in another record, after
already typing what was in there originally, would be extremely unlikely.

I have code that copies the entire content of the record to a separate
history table whenever the form AfterUpdate event is run. Looking at the
history table, I see exactly what the user is talking about. There will
be multiple entries with the correct paragraph of text in the field, and
then, boom!, all of a sudden, out of nowhere, the contents of the field
is replaced, character-for-character, with the contents of another record
for the same field. If the user had done this, they would have to, after
typing the paragraph in the first place, all of a sudden decide to
replace it wit the wrong paragraph of text, and then replicate that other
record's text perfectly. Extremely unlikely.

Since this is the rich textbox control by FMS, and these types of
controls tend to get a little flaky at times, I'm still believing there's
something with the control itself. Since it happens infrequently, and so
far only in conjuction with an error, I see it as a hiccup within the
control, especially since, as noted above, I don't have any code that
updates these controls, and user cause is extremely unlikely.

The fact that no one responding to this thread has ever encountered
anything like this is comforting. But, at the same time, it leaves me
with few ideas as to how to address it. Right now I'm applying the KFC
("keeping fingers crossed") approach. :-(

Thanks,

Neil


"gllincoln" wrote in message
...
Hi Neil,

Just reading through this thread - it's a near certainty that this is
either user error or a coding issue. If you have a one to one
relationship and the field that is 'changing' isn't part of the
relationship, then we can rule out relationship integrity
update/cascade.

I've never seen a control change the contents of a field it wasn't bound
to - but I have seen:
Controls that the programmer thought were bound to one field, that were
actually bound to another field.
Plenty of code that was at fault. (including my own one in a while)

Look very, very closely at all of the events and related code and any
update or append queries that involve a reference to controls bound to
either of the "Joe" fields and any variable used to store or update
these control values - it's extremely likely that the problem is in
there... somewhere.

Hope this helps....
Gordon







"Neil" wrote in message
et...

"Rick Brandt" wrote in message
...
Neil wrote:
"Jeff Boyce" wrote in message
...
Neil

I haven't run across that issue before.

Have you tried searching on-line?


Yes; couldn't find anything.

Does your SQL server table have a primary key defined or did you build
a local index for doing updates? What you are describing is exactly
what can happen if you define a local index for doing updates and
choose a field or combination of fields that are actually NOT unique
in the table. Updates end up affecting multiple rows on the server.


Yes, there's a primary key. This particular form consists of two tables
having a one-to-one relationship, the second table containing primarily
the rich text fields. The primary key of the second table is the
foreign key of first table.

Again, note that when this happens, it's only one or two fields that
are affected, not the entire record. And it only happens in conjunction
with some sort of error.

Dell all our best deals
Dell toutes nos meilleurs offres
Dell alle unsere Top-Angebote
Dell todas nuestras mejores ofertas
Dell alle vores bedste tilbud
Dell kaikki parhaamme käsitellään
Dell tutte le nostre migliori offerte
???????????
???????????
?? ?? ??? ??
Dell ??? ?? ???? ?? ???? ???????

http://www1.euro.dell.com/content/de...6&lid=1 37598




"Ashley" a écrit dans le message de
...
hey, what's up.............................
"Neil" wrote in message
et...
Thanks for your reply, Gordon. But, unfortunately, there is no code that
updates these fields. They're simply bound controls, and are managed by
the control and the ODBC driver.

Furthermore, the fact that the contents of the control are replaced by
the content of a previously saved record in that control indicates that
it can't be user error. These controls hold multiple sentences. For the
user to be able to retype exactly what was in another record, after
already typing what was in there originally, would be extremely unlikely.

I have code that copies the entire content of the record to a separate
history table whenever the form AfterUpdate event is run. Looking at the
history table, I see exactly what the user is talking about. There will
be multiple entries with the correct paragraph of text in the field, and
then, boom!, all of a sudden, out of nowhere, the contents of the field
is replaced, character-for-character, with the contents of another record
for the same field. If the user had done this, they would have to, after
typing the paragraph in the first place, all of a sudden decide to
replace it wit the wrong paragraph of text, and then replicate that other
record's text perfectly. Extremely unlikely.

Since this is the rich textbox control by FMS, and these types of
controls tend to get a little flaky at times, I'm still believing there's
something with the control itself. Since it happens infrequently, and so
far only in conjuction with an error, I see it as a hiccup within the
control, especially since, as noted above, I don't have any code that
updates these controls, and user cause is extremely unlikely.

The fact that no one responding to this thread has ever encountered
anything like this is comforting. But, at the same time, it leaves me
with few ideas as to how to address it. Right now I'm applying the KFC
("keeping fingers crossed") approach. :-(

Thanks,

Neil


"gllincoln" wrote in message
...
Hi Neil,

Just reading through this thread - it's a near certainty that this is
either user error or a coding issue. If you have a one to one
relationship and the field that is 'changing' isn't part of the
relationship, then we can rule out relationship integrity
update/cascade.

I've never seen a control change the contents of a field it wasn't bound
to - but I have seen:
Controls that the programmer thought were bound to one field, that were
actually bound to another field.
Plenty of code that was at fault. (including my own one in a while)

Look very, very closely at all of the events and related code and any
update or append queries that involve a reference to controls bound to
either of the "Joe" fields and any variable used to store or update
these control values - it's extremely likely that the problem is in
there... somewhere.

Hope this helps....
Gordon







"Neil" wrote in message
et...

"Rick Brandt" wrote in message
...
Neil wrote:
"Jeff Boyce" wrote in message
...
Neil

I haven't run across that issue before.

Have you tried searching on-line?


Yes; couldn't find anything.

Does your SQL server table have a primary key defined or did you build
a local index for doing updates? What you are describing is exactly
what can happen if you define a local index for doing updates and
choose a field or combination of fields that are actually NOT unique
in the table. Updates end up affecting multiple rows on the server.


Yes, there's a primary key. This particular form consists of two tables
having a one-to-one relationship, the second table containing primarily
the rich text fields. The primary key of the second table is the
foreign key of first table.

Again, note that when this happens, it's only one or two fields that
are affected, not the entire record. And it only happens in conjunction
with some sort of error.