hey, what's up............. ............... .
"Neil" <nospam@nospam. netwrote in message
news:8YFwj.1050 9$0o7.1113@news svr13.news.prod igy.net...
"Neil" <nospam@nospam. netwrote in message
news:8YFwj.1050 9$0o7.1113@news svr13.news.prod igy.net...
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" <gllincoln@live .comwrote in message
news:3114BEE5-C32B-4405-BFCB-D30873E8FE88@mi crosoft.com...
>
>
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" <gllincoln@live .comwrote in message
news:3114BEE5-C32B-4405-BFCB-D30873E8FE88@mi crosoft.com...
>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" <nospam@nospam. netwrote in message
>news:mIdvj.100 11$0o7.9925@new ssvr13.news.pro digy.net...
>>
>>
>>
>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" <nospam@nospam. netwrote in message
>news:mIdvj.100 11$0o7.9925@new ssvr13.news.pro digy.net...
>>>
>>"Rick Brandt" <rickbrandt2@ho tmail.comwrote in message
>>news:yg2vj.29 81$tW.1807@nlpi 070.nbdc.sbc.co m...
>>>Neil wrote:
>>>>"Jeff Boyce" <nonsense@nonse nse.comwrote in message
>>>>news:%23PCE uuzcIHA.4312@TK 2MSFTNGP03.phx. gbl...
>>>>>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.
>>>
>>>
>>>
>>"Rick Brandt" <rickbrandt2@ho tmail.comwrote in message
>>news:yg2vj.29 81$tW.1807@nlpi 070.nbdc.sbc.co m...
>>>Neil wrote:
>>>>"Jeff Boyce" <nonsense@nonse nse.comwrote in message
>>>>news:%23PCE uuzcIHA.4312@TK 2MSFTNGP03.phx. gbl...
>>>>>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.
>>>
>>>
>>>
>>
>
Comment