Hello,

I have a very strange problem, sometimes, totally random data gets 
overwritten  in one of my dbfs. I have a very large application, using 
dbf/cdx an one of the dbfs is a customer data base, sometimes the city 
of one of the customers is written with another city, this is totally 
random and I don't know where to start....
In the system, the only way to change the city of a given customer, is 
going to a browser, selecting the proper record and editing it, and I 
put a trace there, and that is not what is happening.

Server is Win 2003, stations are Win XP, and Xbase is 1.82

Has anyone seen something like that before ?

Thanks for your help,
Edgar

I have noticed that under certain conditions sometimes the browse can
get out of sync with the database. ie the browse shows you are on record
X but the record number is actually Y. This happens if you move the
pointer in some other routine (maybe a validation?) or change the order
and don't put the record back to the original or refresh the browse.

Always follows Mom's first rule of programming.
"Put things back the way you found them!"

Jim


On 04/06/2010 09:04 AM, Edgar Borger wrote:
> Hello,
> 
> I have a very strange problem, sometimes, totally random data gets
> overwritten  in one of my dbfs. I have a very large application, using
> dbf/cdx an one of the dbfs is a customer data base, sometimes the city
> of one of the customers is written with another city, this is totally
> random and I don't know where to start....
> In the system, the only way to change the city of a given customer, is
> going to a browser, selecting the proper record and editing it, and I
> put a trace there, and that is not what is happening.
> 
> Server is Win 2003, stations are Win XP, and Xbase is 1.82
> 
> Has anyone seen something like that before ?
> 
> Thanks for your help,
> Edgar

Hi Jim,

thanks, but I don't think that is the case, on selecting a record 
(browse row) for edition, I save the contents with before := scatter() 
and after editing I do a after := scatter() and compare the 2 arrays, 
and save the differences in a log dbf, so if the record was not 
positioned correctelly, that would show in my log...

I will keep looking.

Edgar


Em 6/4/2010 11:29, James Loughner escreveu:
> I have noticed that under certain conditions sometimes the browse can
> get out of sync with the database. ie the browse shows you are on record
> X but the record number is actually Y. This happens if you move the
> pointer in some other routine (maybe a validation?) or change the order
> and don't put the record back to the original or refresh the browse.
>
> Always follows Mom's first rule of programming.
> "Put things back the way you found them!"
>
> Jim
>
>
> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>> Hello,
>>
>> I have a very strange problem, sometimes, totally random data gets
>> overwritten  in one of my dbfs. I have a very large application, using
>> dbf/cdx an one of the dbfs is a customer data base, sometimes the city
>> of one of the customers is written with another city, this is totally
>> random and I don't know where to start....
>> In the system, the only way to change the city of a given customer, is
>> going to a browser, selecting the proper record and editing it, and I
>> put a trace there, and that is not what is happening.
>>
>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>
>> Has anyone seen something like that before ?
>>
>> Thanks for your help,
>> Edgar
>

Hi Edgar,

Is there any possibility that you have clicked on another record while 
still in edit mode on a record?

I ask that because using editable browses can be tricky if the 
killInputFocus and setInputFocus callbacks are not perfect.  There may 
be a setdata() that occurs on the wrong record without you realizing it 
- that would probably not show up in your log.

I have spent a lot of time making sure that all my events and callbacks 
work correctly for exactly the above reason.

-Joe

Edgar Borger wrote:
> Hi Jim,
> 
> thanks, but I don't think that is the case, on selecting a record 
> (browse row) for edition, I save the contents with before := scatter() 
> and after editing I do a after := scatter() and compare the 2 arrays, 
> and save the differences in a log dbf, so if the record was not 
> positioned correctelly, that would show in my log...
> 
> I will keep looking.
> 
> Edgar
> 
> 
> Em 6/4/2010 11:29, James Loughner escreveu:
>> I have noticed that under certain conditions sometimes the browse can
>> get out of sync with the database. ie the browse shows you are on record
>> X but the record number is actually Y. This happens if you move the
>> pointer in some other routine (maybe a validation?) or change the order
>> and don't put the record back to the original or refresh the browse.
>>
>> Always follows Mom's first rule of programming.
>> "Put things back the way you found them!"
>>
>> Jim
>>
>>
>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>> Hello,
>>>
>>> I have a very strange problem, sometimes, totally random data gets
>>> overwritten  in one of my dbfs. I have a very large application, using
>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the city
>>> of one of the customers is written with another city, this is totally
>>> random and I don't know where to start....
>>> In the system, the only way to change the city of a given customer, is
>>> going to a browser, selecting the proper record and editing it, and I
>>> put a trace there, and that is not what is happening.
>>>
>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>
>>> Has anyone seen something like that before ?
>>>
>>> Thanks for your help,
>>> Edgar
>>
>

Hi Joe,

well, I have to check on that one... but I don't think that is the case, 
because not all fields are overwritten, just a couple of them, and the 
way I have my edit routine, the whole record would get overwritten. As I 
said before I save the record contents on an array (before := scatter()) 
and compare it to the edited record, (after := scatter()) that way all 
fields would be different and not just a few, or the whole record would 
have been overwritten and I would have duplicated records in my dbf.

Edgar


Em 6/4/2010 14:22, Joe Carrick escreveu:
> Hi Edgar,
>
> Is there any possibility that you have clicked on another record while
> still in edit mode on a record?
>
> I ask that because using editable browses can be tricky if the
> killInputFocus and setInputFocus callbacks are not perfect. There may be
> a setdata() that occurs on the wrong record without you realizing it -
> that would probably not show up in your log.
>
> I have spent a lot of time making sure that all my events and callbacks
> work correctly for exactly the above reason.
>
> -Joe
>
> Edgar Borger wrote:
>> Hi Jim,
>>
>> thanks, but I don't think that is the case, on selecting a record
>> (browse row) for edition, I save the contents with before := scatter()
>> and after editing I do a after := scatter() and compare the 2 arrays,
>> and save the differences in a log dbf, so if the record was not
>> positioned correctelly, that would show in my log...
>>
>> I will keep looking.
>>
>> Edgar
>>
>>
>> Em 6/4/2010 11:29, James Loughner escreveu:
>>> I have noticed that under certain conditions sometimes the browse can
>>> get out of sync with the database. ie the browse shows you are on record
>>> X but the record number is actually Y. This happens if you move the
>>> pointer in some other routine (maybe a validation?) or change the order
>>> and don't put the record back to the original or refresh the browse.
>>>
>>> Always follows Mom's first rule of programming.
>>> "Put things back the way you found them!"
>>>
>>> Jim
>>>
>>>
>>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>>> Hello,
>>>>
>>>> I have a very strange problem, sometimes, totally random data gets
>>>> overwritten in one of my dbfs. I have a very large application, using
>>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the city
>>>> of one of the customers is written with another city, this is totally
>>>> random and I don't know where to start....
>>>> In the system, the only way to change the city of a given customer, is
>>>> going to a browser, selecting the proper record and editing it, and I
>>>> put a trace there, and that is not what is happening.
>>>>
>>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>>
>>>> Has anyone seen something like that before ?
>>>>
>>>> Thanks for your help,
>>>> Edgar
>>>
>>

Edgar,

I have had this issue and I now do what James suggests.  I store the 
record number of the record that has been selected to be edited and then 
use that reference to ensure the correct record is written to with the 
changes.  Before I did this I had 'wandering data' - drove me mad!  Now 
with using the recno() on every edit this does not happen.

HTH,

Best regards,

Bruce


On 06/04/2010 19:14, Edgar Borger wrote:
> Hi Joe,
>
> well, I have to check on that one... but I don't think that is the case,
> because not all fields are overwritten, just a couple of them, and the
> way I have my edit routine, the whole record would get overwritten. As I
> said before I save the record contents on an array (before := scatter())
> and compare it to the edited record, (after := scatter()) that way all
> fields would be different and not just a few, or the whole record would
> have been overwritten and I would have duplicated records in my dbf.
>
> Edgar
>
>
> Em 6/4/2010 14:22, Joe Carrick escreveu:
>> Hi Edgar,
>>
>> Is there any possibility that you have clicked on another record while
>> still in edit mode on a record?
>>
>> I ask that because using editable browses can be tricky if the
>> killInputFocus and setInputFocus callbacks are not perfect. There may be
>> a setdata() that occurs on the wrong record without you realizing it -
>> that would probably not show up in your log.
>>
>> I have spent a lot of time making sure that all my events and callbacks
>> work correctly for exactly the above reason.
>>
>> -Joe
>>
>> Edgar Borger wrote:
>>> Hi Jim,
>>>
>>> thanks, but I don't think that is the case, on selecting a record
>>> (browse row) for edition, I save the contents with before := scatter()
>>> and after editing I do a after := scatter() and compare the 2 arrays,
>>> and save the differences in a log dbf, so if the record was not
>>> positioned correctelly, that would show in my log...
>>>
>>> I will keep looking.
>>>
>>> Edgar
>>>
>>>
>>> Em 6/4/2010 11:29, James Loughner escreveu:
>>>> I have noticed that under certain conditions sometimes the browse can
>>>> get out of sync with the database. ie the browse shows you are on
>>>> record
>>>> X but the record number is actually Y. This happens if you move the
>>>> pointer in some other routine (maybe a validation?) or change the order
>>>> and don't put the record back to the original or refresh the browse.
>>>>
>>>> Always follows Mom's first rule of programming.
>>>> "Put things back the way you found them!"
>>>>
>>>> Jim
>>>>
>>>>
>>>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>>>> Hello,
>>>>>
>>>>> I have a very strange problem, sometimes, totally random data gets
>>>>> overwritten in one of my dbfs. I have a very large application, using
>>>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the city
>>>>> of one of the customers is written with another city, this is totally
>>>>> random and I don't know where to start....
>>>>> In the system, the only way to change the city of a given customer, is
>>>>> going to a browser, selecting the proper record and editing it, and I
>>>>> put a trace there, and that is not what is happening.
>>>>>
>>>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>>>
>>>>> Has anyone seen something like that before ?
>>>>>
>>>>> Thanks for your help,
>>>>> Edgar
>>>>
>>>
>

You have some function somewhere that is changing the record pointer and
not returning it to a the original position. ie breaking Mom's Rule

If you are running all in a single thread and you allow your user to use
other functions that may change the pointer in the problem DBF then you
have a basic design problem. Using multiple threads can also help here.

Jim





On 04/07/2010 04:43 AM, Bruce Carroll wrote:
> Edgar,
> 
> I have had this issue and I now do what James suggests.  I store the
> record number of the record that has been selected to be edited and then
> use that reference to ensure the correct record is written to with the
> changes.  Before I did this I had 'wandering data' - drove me mad!  Now
> with using the recno() on every edit this does not happen.
> 
> HTH,
> 
> Best regards,
> 
> Bruce
> 
> 
> On 06/04/2010 19:14, Edgar Borger wrote:
>> Hi Joe,
>>
>> well, I have to check on that one... but I don't think that is the case,
>> because not all fields are overwritten, just a couple of them, and the
>> way I have my edit routine, the whole record would get overwritten. As I
>> said before I save the record contents on an array (before := scatter())
>> and compare it to the edited record, (after := scatter()) that way all
>> fields would be different and not just a few, or the whole record would
>> have been overwritten and I would have duplicated records in my dbf.
>>
>> Edgar
>>
>>
>> Em 6/4/2010 14:22, Joe Carrick escreveu:
>>> Hi Edgar,
>>>
>>> Is there any possibility that you have clicked on another record while
>>> still in edit mode on a record?
>>>
>>> I ask that because using editable browses can be tricky if the
>>> killInputFocus and setInputFocus callbacks are not perfect. There may be
>>> a setdata() that occurs on the wrong record without you realizing it -
>>> that would probably not show up in your log.
>>>
>>> I have spent a lot of time making sure that all my events and callbacks
>>> work correctly for exactly the above reason.
>>>
>>> -Joe
>>>
>>> Edgar Borger wrote:
>>>> Hi Jim,
>>>>
>>>> thanks, but I don't think that is the case, on selecting a record
>>>> (browse row) for edition, I save the contents with before := scatter()
>>>> and after editing I do a after := scatter() and compare the 2 arrays,
>>>> and save the differences in a log dbf, so if the record was not
>>>> positioned correctelly, that would show in my log...
>>>>
>>>> I will keep looking.
>>>>
>>>> Edgar
>>>>
>>>>
>>>> Em 6/4/2010 11:29, James Loughner escreveu:
>>>>> I have noticed that under certain conditions sometimes the browse can
>>>>> get out of sync with the database. ie the browse shows you are on
>>>>> record
>>>>> X but the record number is actually Y. This happens if you move the
>>>>> pointer in some other routine (maybe a validation?) or change the
>>>>> order
>>>>> and don't put the record back to the original or refresh the browse.
>>>>>
>>>>> Always follows Mom's first rule of programming.
>>>>> "Put things back the way you found them!"
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I have a very strange problem, sometimes, totally random data gets
>>>>>> overwritten in one of my dbfs. I have a very large application, using
>>>>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the
>>>>>> city
>>>>>> of one of the customers is written with another city, this is totally
>>>>>> random and I don't know where to start....
>>>>>> In the system, the only way to change the city of a given
>>>>>> customer, is
>>>>>> going to a browser, selecting the proper record and editing it, and I
>>>>>> put a trace there, and that is not what is happening.
>>>>>>
>>>>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>>>>
>>>>>> Has anyone seen something like that before ?
>>>>>>
>>>>>> Thanks for your help,
>>>>>> Edgar
>>>>>
>>>>
>>

thanks for the advice, I will have another look at all my routines to 
try to figure out what the hell the customer is doing, always very 
difficult, they seem to have an infinite creativity to disrupt whatever 
piece of software you write !!!!

thanks again and regards,
Edgar

Em 7/4/2010 11:38, James Loughner escreveu:
> You have some function somewhere that is changing the record pointer and
> not returning it to a the original position. ie breaking Mom's Rule
>
> If you are running all in a single thread and you allow your user to use
> other functions that may change the pointer in the problem DBF then you
> have a basic design problem. Using multiple threads can also help here.
>
> Jim
>
>
>
>
>
> On 04/07/2010 04:43 AM, Bruce Carroll wrote:
>> Edgar,
>>
>> I have had this issue and I now do what James suggests.  I store the
>> record number of the record that has been selected to be edited and then
>> use that reference to ensure the correct record is written to with the
>> changes.  Before I did this I had 'wandering data' - drove me mad!  Now
>> with using the recno() on every edit this does not happen.
>>
>> HTH,
>>
>> Best regards,
>>
>> Bruce
>>
>>
>> On 06/04/2010 19:14, Edgar Borger wrote:
>>> Hi Joe,
>>>
>>> well, I have to check on that one... but I don't think that is the case,
>>> because not all fields are overwritten, just a couple of them, and the
>>> way I have my edit routine, the whole record would get overwritten. As I
>>> said before I save the record contents on an array (before := scatter())
>>> and compare it to the edited record, (after := scatter()) that way all
>>> fields would be different and not just a few, or the whole record would
>>> have been overwritten and I would have duplicated records in my dbf.
>>>
>>> Edgar
>>>
>>>
>>> Em 6/4/2010 14:22, Joe Carrick escreveu:
>>>> Hi Edgar,
>>>>
>>>> Is there any possibility that you have clicked on another record while
>>>> still in edit mode on a record?
>>>>
>>>> I ask that because using editable browses can be tricky if the
>>>> killInputFocus and setInputFocus callbacks are not perfect. There may be
>>>> a setdata() that occurs on the wrong record without you realizing it -
>>>> that would probably not show up in your log.
>>>>
>>>> I have spent a lot of time making sure that all my events and callbacks
>>>> work correctly for exactly the above reason.
>>>>
>>>> -Joe
>>>>
>>>> Edgar Borger wrote:
>>>>> Hi Jim,
>>>>>
>>>>> thanks, but I don't think that is the case, on selecting a record
>>>>> (browse row) for edition, I save the contents with before := scatter()
>>>>> and after editing I do a after := scatter() and compare the 2 arrays,
>>>>> and save the differences in a log dbf, so if the record was not
>>>>> positioned correctelly, that would show in my log...
>>>>>
>>>>> I will keep looking.
>>>>>
>>>>> Edgar
>>>>>
>>>>>
>>>>> Em 6/4/2010 11:29, James Loughner escreveu:
>>>>>> I have noticed that under certain conditions sometimes the browse can
>>>>>> get out of sync with the database. ie the browse shows you are on
>>>>>> record
>>>>>> X but the record number is actually Y. This happens if you move the
>>>>>> pointer in some other routine (maybe a validation?) or change the
>>>>>> order
>>>>>> and don't put the record back to the original or refresh the browse.
>>>>>>
>>>>>> Always follows Mom's first rule of programming.
>>>>>> "Put things back the way you found them!"
>>>>>>
>>>>>> Jim
>>>>>>
>>>>>>
>>>>>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I have a very strange problem, sometimes, totally random data gets
>>>>>>> overwritten in one of my dbfs. I have a very large application, using
>>>>>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the
>>>>>>> city
>>>>>>> of one of the customers is written with another city, this is totally
>>>>>>> random and I don't know where to start....
>>>>>>> In the system, the only way to change the city of a given
>>>>>>> customer, is
>>>>>>> going to a browser, selecting the proper record and editing it, and I
>>>>>>> put a trace there, and that is not what is happening.
>>>>>>>
>>>>>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>>>>>
>>>>>>> Has anyone seen something like that before ?
>>>>>>>
>>>>>>> Thanks for your help,
>>>>>>> Edgar
>>>>>>
>>>>>
>>>
>

Is there a way for them to open multiple copies of your task?  Any 
secondary tasks that access the same database?

I have a very large Accounting App that depends heavily on modal 
dialogs.  I have one main dialog that provides menu access to hundreds 
of tasks.  Each task that provides for editing of databases in any way 
is contained within a modal dialog and I disable the menubar and 
anything else that would allow the user to mess things up.  If it just a 
reporting task such as a browse or printing then I provide it as a 
separate thread.

Of course, you have to make sure that anything you disable gets enabled 
when the task is finished.  Jim's MOM's Rule 

And always remember that the users will have their own way of using the 
system and anything that you don't expect them to do (and don't test 
for) needs to be prevented.  Ten thousand monkeys pounding on the 
keyboard probably couldn't cause as much havoc as 5 users.

-Joe

Edgar Borger wrote:
> thanks for the advice, I will have another look at all my routines to 
> try to figure out what the hell the customer is doing, always very 
> difficult, they seem to have an infinite creativity to disrupt 
> whatever piece of software you write !!!!
>
> thanks again and regards,
> Edgar
>
> Em 7/4/2010 11:38, James Loughner escreveu:
>> You have some function somewhere that is changing the record pointer and
>> not returning it to a the original position. ie breaking Mom's Rule
>>
>> If you are running all in a single thread and you allow your user to use
>> other functions that may change the pointer in the problem DBF then you
>> have a basic design problem. Using multiple threads can also help here.
>>
>> Jim
>>
>>
>>
>>
>>
>> On 04/07/2010 04:43 AM, Bruce Carroll wrote:
>>> Edgar,
>>>
>>> I have had this issue and I now do what James suggests.  I store the
>>> record number of the record that has been selected to be edited and 
>>> then
>>> use that reference to ensure the correct record is written to with the
>>> changes.  Before I did this I had 'wandering data' - drove me mad!  Now
>>> with using the recno() on every edit this does not happen.
>>>
>>> HTH,
>>>
>>> Best regards,
>>>
>>> Bruce
>>>
>>>
>>> On 06/04/2010 19:14, Edgar Borger wrote:
>>>> Hi Joe,
>>>>
>>>> well, I have to check on that one... but I don't think that is the 
>>>> case,
>>>> because not all fields are overwritten, just a couple of them, and the
>>>> way I have my edit routine, the whole record would get overwritten. 
>>>> As I
>>>> said before I save the record contents on an array (before := 
>>>> scatter())
>>>> and compare it to the edited record, (after := scatter()) that way all
>>>> fields would be different and not just a few, or the whole record 
>>>> would
>>>> have been overwritten and I would have duplicated records in my dbf.
>>>>
>>>> Edgar
>>>>
>>>>
>>>> Em 6/4/2010 14:22, Joe Carrick escreveu:
>>>>> Hi Edgar,
>>>>>
>>>>> Is there any possibility that you have clicked on another record 
>>>>> while
>>>>> still in edit mode on a record?
>>>>>
>>>>> I ask that because using editable browses can be tricky if the
>>>>> killInputFocus and setInputFocus callbacks are not perfect. There 
>>>>> may be
>>>>> a setdata() that occurs on the wrong record without you realizing 
>>>>> it -
>>>>> that would probably not show up in your log.
>>>>>
>>>>> I have spent a lot of time making sure that all my events and 
>>>>> callbacks
>>>>> work correctly for exactly the above reason.
>>>>>
>>>>> -Joe
>>>>>
>>>>> Edgar Borger wrote:
>>>>>> Hi Jim,
>>>>>>
>>>>>> thanks, but I don't think that is the case, on selecting a record
>>>>>> (browse row) for edition, I save the contents with before := 
>>>>>> scatter()
>>>>>> and after editing I do a after := scatter() and compare the 2 
>>>>>> arrays,
>>>>>> and save the differences in a log dbf, so if the record was not
>>>>>> positioned correctelly, that would show in my log...
>>>>>>
>>>>>> I will keep looking.
>>>>>>
>>>>>> Edgar
>>>>>>
>>>>>>
>>>>>> Em 6/4/2010 11:29, James Loughner escreveu:
>>>>>>> I have noticed that under certain conditions sometimes the 
>>>>>>> browse can
>>>>>>> get out of sync with the database. ie the browse shows you are on
>>>>>>> record
>>>>>>> X but the record number is actually Y. This happens if you move the
>>>>>>> pointer in some other routine (maybe a validation?) or change the
>>>>>>> order
>>>>>>> and don't put the record back to the original or refresh the 
>>>>>>> browse.
>>>>>>>
>>>>>>> Always follows Mom's first rule of programming.
>>>>>>> "Put things back the way you found them!"
>>>>>>>
>>>>>>> Jim
>>>>>>>
>>>>>>>
>>>>>>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I have a very strange problem, sometimes, totally random data gets
>>>>>>>> overwritten in one of my dbfs. I have a very large application, 
>>>>>>>> using
>>>>>>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the
>>>>>>>> city
>>>>>>>> of one of the customers is written with another city, this is 
>>>>>>>> totally
>>>>>>>> random and I don't know where to start....
>>>>>>>> In the system, the only way to change the city of a given
>>>>>>>> customer, is
>>>>>>>> going to a browser, selecting the proper record and editing it, 
>>>>>>>> and I
>>>>>>>> put a trace there, and that is not what is happening.
>>>>>>>>
>>>>>>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>>>>>>
>>>>>>>> Has anyone seen something like that before ?
>>>>>>>>
>>>>>>>> Thanks for your help,
>>>>>>>> Edgar
>>>>>>>
>>>>>>
>>>>
>>
>

Hi Joe,

I totally agree !

my app is single threaded, and once one function is started no other 
function can be called.
I am updating the system to 1.9, let's see how that reacts.....

Regards,
Edgar

Em 7/4/2010 22:06, Joe Carrick escreveu:
> Is there a way for them to open multiple copies of your task?  Any
> secondary tasks that access the same database?
>
> I have a very large Accounting App that depends heavily on modal
> dialogs. I have one main dialog that provides menu access to hundreds of
> tasks. Each task that provides for editing of databases in any way is
> contained within a modal dialog and I disable the menubar and anything
> else that would allow the user to mess things up. If it just a reporting
> task such as a browse or printing then I provide it as a separate thread.
>
> Of course, you have to make sure that anything you disable gets enabled
> when the task is finished. Jim's MOM's Rule 
>
> And always remember that the users will have their own way of using the
> system and anything that you don't expect them to do (and don't test
> for) needs to be prevented. Ten thousand monkeys pounding on the
> keyboard probably couldn't cause as much havoc as 5 users.
>
> -Joe
>
> Edgar Borger wrote:
>> thanks for the advice, I will have another look at all my routines to
>> try to figure out what the hell the customer is doing, always very
>> difficult, they seem to have an infinite creativity to disrupt
>> whatever piece of software you write !!!!
>>
>> thanks again and regards,
>> Edgar
>>
>> Em 7/4/2010 11:38, James Loughner escreveu:
>>> You have some function somewhere that is changing the record pointer and
>>> not returning it to a the original position. ie breaking Mom's Rule
>>>
>>> If you are running all in a single thread and you allow your user to use
>>> other functions that may change the pointer in the problem DBF then you
>>> have a basic design problem. Using multiple threads can also help here.
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>>
>>> On 04/07/2010 04:43 AM, Bruce Carroll wrote:
>>>> Edgar,
>>>>
>>>> I have had this issue and I now do what James suggests. I store the
>>>> record number of the record that has been selected to be edited and
>>>> then
>>>> use that reference to ensure the correct record is written to with the
>>>> changes. Before I did this I had 'wandering data' - drove me mad! Now
>>>> with using the recno() on every edit this does not happen.
>>>>
>>>> HTH,
>>>>
>>>> Best regards,
>>>>
>>>> Bruce
>>>>
>>>>
>>>> On 06/04/2010 19:14, Edgar Borger wrote:
>>>>> Hi Joe,
>>>>>
>>>>> well, I have to check on that one... but I don't think that is the
>>>>> case,
>>>>> because not all fields are overwritten, just a couple of them, and the
>>>>> way I have my edit routine, the whole record would get overwritten.
>>>>> As I
>>>>> said before I save the record contents on an array (before :=
>>>>> scatter())
>>>>> and compare it to the edited record, (after := scatter()) that way all
>>>>> fields would be different and not just a few, or the whole record
>>>>> would
>>>>> have been overwritten and I would have duplicated records in my dbf.
>>>>>
>>>>> Edgar
>>>>>
>>>>>
>>>>> Em 6/4/2010 14:22, Joe Carrick escreveu:
>>>>>> Hi Edgar,
>>>>>>
>>>>>> Is there any possibility that you have clicked on another record
>>>>>> while
>>>>>> still in edit mode on a record?
>>>>>>
>>>>>> I ask that because using editable browses can be tricky if the
>>>>>> killInputFocus and setInputFocus callbacks are not perfect. There
>>>>>> may be
>>>>>> a setdata() that occurs on the wrong record without you realizing
>>>>>> it -
>>>>>> that would probably not show up in your log.
>>>>>>
>>>>>> I have spent a lot of time making sure that all my events and
>>>>>> callbacks
>>>>>> work correctly for exactly the above reason.
>>>>>>
>>>>>> -Joe
>>>>>>
>>>>>> Edgar Borger wrote:
>>>>>>> Hi Jim,
>>>>>>>
>>>>>>> thanks, but I don't think that is the case, on selecting a record
>>>>>>> (browse row) for edition, I save the contents with before :=
>>>>>>> scatter()
>>>>>>> and after editing I do a after := scatter() and compare the 2
>>>>>>> arrays,
>>>>>>> and save the differences in a log dbf, so if the record was not
>>>>>>> positioned correctelly, that would show in my log...
>>>>>>>
>>>>>>> I will keep looking.
>>>>>>>
>>>>>>> Edgar
>>>>>>>
>>>>>>>
>>>>>>> Em 6/4/2010 11:29, James Loughner escreveu:
>>>>>>>> I have noticed that under certain conditions sometimes the
>>>>>>>> browse can
>>>>>>>> get out of sync with the database. ie the browse shows you are on
>>>>>>>> record
>>>>>>>> X but the record number is actually Y. This happens if you move the
>>>>>>>> pointer in some other routine (maybe a validation?) or change the
>>>>>>>> order
>>>>>>>> and don't put the record back to the original or refresh the
>>>>>>>> browse.
>>>>>>>>
>>>>>>>> Always follows Mom's first rule of programming.
>>>>>>>> "Put things back the way you found them!"
>>>>>>>>
>>>>>>>> Jim
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I have a very strange problem, sometimes, totally random data gets
>>>>>>>>> overwritten in one of my dbfs. I have a very large application,
>>>>>>>>> using
>>>>>>>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the
>>>>>>>>> city
>>>>>>>>> of one of the customers is written with another city, this is
>>>>>>>>> totally
>>>>>>>>> random and I don't know where to start....
>>>>>>>>> In the system, the only way to change the city of a given
>>>>>>>>> customer, is
>>>>>>>>> going to a browser, selecting the proper record and editing it,
>>>>>>>>> and I
>>>>>>>>> put a trace there, and that is not what is happening.
>>>>>>>>>
>>>>>>>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>>>>>>>
>>>>>>>>> Has anyone seen something like that before ?
>>>>>>>>>
>>>>>>>>> Thanks for your help,
>>>>>>>>> Edgar
>>>>>>>>
>>>>>>>
>>>>>
>>>
>>

You might want to look for OrdSetFocus changes that are not reset. This
will cause the browse to be out of sync until full refreshed.



Jim

On 04/08/2010 09:19 AM, Edgar Borger wrote:
> Hi Joe,
> 
> I totally agree !
> 
> my app is single threaded, and once one function is started no other
> function can be called.
> I am updating the system to 1.9, let's see how that reacts.....
> 
> Regards,
> Edgar
> 
> Em 7/4/2010 22:06, Joe Carrick escreveu:
>> Is there a way for them to open multiple copies of your task?  Any
>> secondary tasks that access the same database?
>>
>> I have a very large Accounting App that depends heavily on modal
>> dialogs. I have one main dialog that provides menu access to hundreds of
>> tasks. Each task that provides for editing of databases in any way is
>> contained within a modal dialog and I disable the menubar and anything
>> else that would allow the user to mess things up. If it just a reporting
>> task such as a browse or printing then I provide it as a separate thread.
>>
>> Of course, you have to make sure that anything you disable gets enabled
>> when the task is finished. Jim's MOM's Rule 
>>
>> And always remember that the users will have their own way of using the
>> system and anything that you don't expect them to do (and don't test
>> for) needs to be prevented. Ten thousand monkeys pounding on the
>> keyboard probably couldn't cause as much havoc as 5 users.
>>
>> -Joe
>>
>> Edgar Borger wrote:
>>> thanks for the advice, I will have another look at all my routines to
>>> try to figure out what the hell the customer is doing, always very
>>> difficult, they seem to have an infinite creativity to disrupt
>>> whatever piece of software you write !!!!
>>>
>>> thanks again and regards,
>>> Edgar
>>>
>>> Em 7/4/2010 11:38, James Loughner escreveu:
>>>> You have some function somewhere that is changing the record pointer
>>>> and
>>>> not returning it to a the original position. ie breaking Mom's Rule
>>>>
>>>> If you are running all in a single thread and you allow your user to
>>>> use
>>>> other functions that may change the pointer in the problem DBF then you
>>>> have a basic design problem. Using multiple threads can also help here.
>>>>
>>>> Jim
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 04/07/2010 04:43 AM, Bruce Carroll wrote:
>>>>> Edgar,
>>>>>
>>>>> I have had this issue and I now do what James suggests. I store the
>>>>> record number of the record that has been selected to be edited and
>>>>> then
>>>>> use that reference to ensure the correct record is written to with the
>>>>> changes. Before I did this I had 'wandering data' - drove me mad! Now
>>>>> with using the recno() on every edit this does not happen.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Bruce
>>>>>
>>>>>
>>>>> On 06/04/2010 19:14, Edgar Borger wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> well, I have to check on that one... but I don't think that is the
>>>>>> case,
>>>>>> because not all fields are overwritten, just a couple of them, and
>>>>>> the
>>>>>> way I have my edit routine, the whole record would get overwritten.
>>>>>> As I
>>>>>> said before I save the record contents on an array (before :=
>>>>>> scatter())
>>>>>> and compare it to the edited record, (after := scatter()) that way
>>>>>> all
>>>>>> fields would be different and not just a few, or the whole record
>>>>>> would
>>>>>> have been overwritten and I would have duplicated records in my dbf.
>>>>>>
>>>>>> Edgar
>>>>>>
>>>>>>
>>>>>> Em 6/4/2010 14:22, Joe Carrick escreveu:
>>>>>>> Hi Edgar,
>>>>>>>
>>>>>>> Is there any possibility that you have clicked on another record
>>>>>>> while
>>>>>>> still in edit mode on a record?
>>>>>>>
>>>>>>> I ask that because using editable browses can be tricky if the
>>>>>>> killInputFocus and setInputFocus callbacks are not perfect. There
>>>>>>> may be
>>>>>>> a setdata() that occurs on the wrong record without you realizing
>>>>>>> it -
>>>>>>> that would probably not show up in your log.
>>>>>>>
>>>>>>> I have spent a lot of time making sure that all my events and
>>>>>>> callbacks
>>>>>>> work correctly for exactly the above reason.
>>>>>>>
>>>>>>> -Joe
>>>>>>>
>>>>>>> Edgar Borger wrote:
>>>>>>>> Hi Jim,
>>>>>>>>
>>>>>>>> thanks, but I don't think that is the case, on selecting a record
>>>>>>>> (browse row) for edition, I save the contents with before :=
>>>>>>>> scatter()
>>>>>>>> and after editing I do a after := scatter() and compare the 2
>>>>>>>> arrays,
>>>>>>>> and save the differences in a log dbf, so if the record was not
>>>>>>>> positioned correctelly, that would show in my log...
>>>>>>>>
>>>>>>>> I will keep looking.
>>>>>>>>
>>>>>>>> Edgar
>>>>>>>>
>>>>>>>>
>>>>>>>> Em 6/4/2010 11:29, James Loughner escreveu:
>>>>>>>>> I have noticed that under certain conditions sometimes the
>>>>>>>>> browse can
>>>>>>>>> get out of sync with the database. ie the browse shows you are on
>>>>>>>>> record
>>>>>>>>> X but the record number is actually Y. This happens if you move
>>>>>>>>> the
>>>>>>>>> pointer in some other routine (maybe a validation?) or change the
>>>>>>>>> order
>>>>>>>>> and don't put the record back to the original or refresh the
>>>>>>>>> browse.
>>>>>>>>>
>>>>>>>>> Always follows Mom's first rule of programming.
>>>>>>>>> "Put things back the way you found them!"
>>>>>>>>>
>>>>>>>>> Jim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 04/06/2010 09:04 AM, Edgar Borger wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> I have a very strange problem, sometimes, totally random data
>>>>>>>>>> gets
>>>>>>>>>> overwritten in one of my dbfs. I have a very large application,
>>>>>>>>>> using
>>>>>>>>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the
>>>>>>>>>> city
>>>>>>>>>> of one of the customers is written with another city, this is
>>>>>>>>>> totally
>>>>>>>>>> random and I don't know where to start....
>>>>>>>>>> In the system, the only way to change the city of a given
>>>>>>>>>> customer, is
>>>>>>>>>> going to a browser, selecting the proper record and editing it,
>>>>>>>>>> and I
>>>>>>>>>> put a trace there, and that is not what is happening.
>>>>>>>>>>
>>>>>>>>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>>>>>>>>
>>>>>>>>>> Has anyone seen something like that before ?
>>>>>>>>>>
>>>>>>>>>> Thanks for your help,
>>>>>>>>>> Edgar
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>

I've found this may happen if you don't do  a DbCommit() after
changing any DBF data

Always Edgar Borger <eborger@terra.com.br> wrote:

>Hello,
>
>I have a very strange problem, sometimes, totally random data gets 
>overwritten  in one of my dbfs. I have a very large application, using 
>dbf/cdx an one of the dbfs is a customer data base, sometimes the city 
>of one of the customers is written with another city, this is totally 
>random and I don't know where to start....
>In the system, the only way to change the city of a given customer, is 
>going to a browser, selecting the proper record and editing it, and I 
>put a trace there, and that is not what is happening.
>
>Server is Win 2003, stations are Win XP, and Xbase is 1.82
>
>Has anyone seen something like that before ?
>
>Thanks for your help,
>Edgar

I do a DbGoto( recno() ), it's supposed to be the same thing, is it ?

Thanks,
Edgar

Em 8/4/2010 20:57, Geoffrey Cohen escreveu:
> I've found this may happen if you don't do  a DbCommit() after
> changing any DBF data
>
> Always Edgar Borger<eborger@terra.com.br>  wrote:
>
>> Hello,
>>
>> I have a very strange problem, sometimes, totally random data gets
>> overwritten  in one of my dbfs. I have a very large application, using
>> dbf/cdx an one of the dbfs is a customer data base, sometimes the city
>> of one of the customers is written with another city, this is totally
>> random and I don't know where to start....
>> In the system, the only way to change the city of a given customer, is
>> going to a browser, selecting the proper record and editing it, and I
>> put a trace there, and that is not what is happening.
>>
>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>
>> Has anyone seen something like that before ?
>>
>> Thanks for your help,
>> Edgar
>

Depends on what recno() is. DBGoto(recno()) forces a read of the data at
recno(). To save bandwidth skips generally do not read the record
pointed to. DBGoto(recno()) forces the read. The problem is with GUI
event driven apps. You can never be sure what the user has done prior to
any given operation. If a record pointer is moved and either the browse
not refreshed or the record pointer not returned to the previous value a
browse may not be showing the record that is actually the current
pointer. That is why it is very important to follow Mom's rule
religiously in all validation and other functions that may move a record
pointer. This applies to all database operation like setting the order
filters scopes etc. Anything that may change the database state in the
thread that does not also refresh the browse. Otherwise you get spooky
stuff happening.

Jim


On 04/09/2010 10:00 AM, Edgar Borger wrote:
> I do a DbGoto( recno() ), it's supposed to be the same thing, is it ?
> 
> Thanks,
> Edgar
> 
> Em 8/4/2010 20:57, Geoffrey Cohen escreveu:
>> I've found this may happen if you don't do  a DbCommit() after
>> changing any DBF data
>>
>> Always Edgar Borger<eborger@terra.com.br>  wrote:
>>
>>> Hello,
>>>
>>> I have a very strange problem, sometimes, totally random data gets
>>> overwritten  in one of my dbfs. I have a very large application, using
>>> dbf/cdx an one of the dbfs is a customer data base, sometimes the city
>>> of one of the customers is written with another city, this is totally
>>> random and I don't know where to start....
>>> In the system, the only way to change the city of a given customer, is
>>> going to a browser, selecting the proper record and editing it, and I
>>> put a trace there, and that is not what is happening.
>>>
>>> Server is Win 2003, stations are Win XP, and Xbase is 1.82
>>>
>>> Has anyone seen something like that before ?
>>>
>>> Thanks for your help,
>>> Edgar
>>
>