Data disappears random while saving new record

[Nifrabar]

Hi!
In my datainput screen it happens that sometimes certain fields get blank just prior to get saved.
The datasource is a buffered view. Fields which get blank are both numeric as well as character type.
What might be an efficient wy to trace?
-Bart

 

[Mike Lewis]

Bart, do you mean that the fields appear blank on the screen? Or do they actually have blank (empty or zero) values in them?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[IlyaRabyy]

Bart,
One of the things you might want to try is to make sure that the record pointer in your data source haven't "slid" to the EOF.
I, personally, do not like to bind a recordset (to be it a table, or stored view, buffered or not) to the data entry controls, IYAMO.
I prefer to have those Text and all the other data entry boxes "free", and validate the User's entries in the FORM.cmdGo.Click() event procedure. (Occasionally, but rarely, I also do some critical check-ups in the TextBox's Valid() methods).

Just MHO, but HTH.

Regards,

Ilya

 

[Koen Piller]

Bart,
I would put a break in the code where you suspect the data gets changed, or maybe a few lines ahead, and set a watch on the view content. This should give you a response which line of code makes your data to be replaced with a blank value.

Groet,
Koen

 

[Nifrabar]

Mike:
The fields appear blank on the screen. Meanwhile the controlsource lost the given input.

Ilya:
Pls note that it seems that not all fields turn into blanks. IMHU when this has to do with EOF() all fields should blank.

Koen,
Agreed when this happens constantly. I have been reported that dozens of new records could be added in normal way and than, out of the blue a few fields got blank during save-procedure.

-Bart

 

[Dan Freeman]

It this were just one field "getting blank" I'd say it's probably the old focus leaving the control problem. If the save button is a toolbar button, focus doesn't leave .CurrentControl so its value never gets written to the buffer.

But you say it's several controls in a single record, yes?

 

[Mike Lewis]

Bart, do you have an error-logging routine in place? By that I mean a routine that gets called when a run-time error occurs, and which logs the complete state of the environment at that point: the contents of variables, a list of open tables in each data session, the position of record pointers, the current call stack, all the current SET settings, and whatever else you can think of?

If so, you could insert a test for an empty value for the fields in question at a suitable point in your code. If the test succeeds (that is, the field is blank), then call the error-logger (without halting the program). Then get the users to send you the error logs.

That should give you the information you need to understand what's going on, without affecting the majority of cases where the problem never occurs.

If you don't have an error-logger, you should seriously consider writing one. It's an enormous help in debugging, especially when you're not present when the error actually happens, and when you're unable to reproduce it in the development environment.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Nifrabar]

Danfreeman,
I know this lostfocus issue and have a routine which writes the value of a textbox into the datasource while using a toolbar button. And yes, I've been reported that several fields turn into blank during saving. I have seen the effect just a single time by myself as well. So no doubt something is wrong.

Mike,
Good idea to include such a routine. Currently I don't have one but probably not that difficult to provide.
To prevent reinventing the wheel: Should there be an example of such a routine somewhere?

-Bart

 

[Mike Lewis]

Should there be an example of such a routine somewhere?

1001 Things You Always Wanted to Know About Visual FoxPro - page 354. But use that as a starting point only. There's a lot more you can add to it. In particular, you can log the following:

- Date and time of error

- VFP version number, Windows version

- Name of currently logged-in user; machine name

- Name of active form

- Current data session ID

- In each data session: a list of open tables, views, etc.

- For each open table, view, etc: current record pointer, contents of current record, active tag, record count, etc.

- Calling stack

- All memory variables

- All SET settings

- Anything else you can think of

If you're not sure how to obtain any of those items, just shout.

Mike











__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Nifrabar]

Mike,
How could I forget '1001 things'!
Going to study the relevant code.
Than, after I implemented the code a new challenge is to find a usefull 'checkpoint'.
BTW, I am using an adapted version of the save routine in chap. 8
-Bart

 

[Mike Lewis]

after I implemented the code a new challenge is to find a usefull 'checkpoint'

Yes, that's going to be difficult. I guess you need it to be some time after the user has finished editing but before you actually commit the values.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[IlyaRabyy]

Bart,
It was not evidently clear from your original post that it's not all but just several of the fields end up blank in the target table, hence my idea about EOF - me apologize.

Another (I hope not as stupid) idea: FLUSH FORCE in the cmdSave.Click() (or whatever have you) event procedure.

HTH.

Regards,

Ilya

 

[Nifrabar]

Ilya,
No need to appologize. Every help means you spent some time for my problem.
Re flush force, I don't know this command. As the help file also talks about fopen I am wondering wether or not this command can be used in multi-user environment with buffered data.
Do you know more about flush force?
-Bart

 

[Mike Lewis]

FLUSH FORCE has got nothing to do with FOPEN() - or any other low-level file functions. Are you getting it confused with FFLUSH().

Essentially, you call FLUSH FORCE to ensure that any updates you make to a DBF() get physically written to disk. I'm not convinced that it will solve your present problem, but it would certainly be worth trying.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Mike Lewis]

Just to add ....

You say your table is buffered. In that case, the best time to call FLUSH FORCE would be after you call TABLEUPDATE().

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Nifrabar]

Mike,
Have a look at the help-file where it specific mention fopen while talking about parameters.

Parameters
[IN nWorkArea | cTableAlias] | [cFileSpec]
Specifies the work area number, table alias, or the name of a currently opened file name, for example, an index file or a file opened using the FOPEN( ) function. When specifying a file name, include the path, for example, C:\MyApp\MyTable.dbf.

Anyway I'm going to give it a try. Does not requires much efforts for that.
-Bart

 

[Mike Lewis]

Bart, you're right. I missed that mention of FOPEN(). But it doesn't affect things either way.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Koen Piller]

Nifrabar,
drop me an email, I can mail you an errorlogging.pjx
koenDOTpillerATgmailDOTcom
Regards,
Jockey(2)

 

[Olaf Doschke]

Recently I made an error that puzzled me, the explanation was easy enough, once it was identified:

I had a mix of bound and unbound textboxes on a form, the unbound textboxes were to enter values for filtering data via a filter button. The rest of the form mainly is a grid and shows a list you can filter. But also some detail fields for display, of which one was bound to the same table, as the grid.

At some point when using the form for some time, I saw some records having gone blank in one field in the grid.

What was the reason?

Beside the filter button I also had a clear filter button, that used SetAll("Value","","Textbox") to clear the unbound filter textboxes. But of course that also cleared the one bound textbox, which in turn blanked the field it is bound to. This even happens, if the textbox is set Readonly, because that doesn't prevent programmatic changes.

So you see, you can have this side effect of blanking a field in code not even mentioning a field or table name.

Conclude: You need to debug from the first line of your save button click code, and keep a browse window of the table in question open aside of single stepping through the code and you will detect where fields go blank.

Bye, Olaf.

 

[Mike Lewis]

You need to debug from the first line of your save button click code, and keep a browse window of the table in question open aside of single stepping through the code and you will detect where fields go blank.

Good point, Olaf - provided Bart can reproduce the error in the development environment (he said it was only seen by some end users, and only intermittently).

If he can reproduce the error, another approach might be to set a breakpoint on the Value property of the textbox. In other words, have the program break when EMPTY(MyForm.Text1.Value) becomes .T.


Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy