Weird behavior

[Dan Freeman]

I've been seeing strange error reports from a vertical market app that runs inventory and point of sale at 1100 locations across the US and Canada. In random places (and with 1100 locations reporting, it truly does seem random), we get an "Operator/Operand mismatch" error that totally bypasses the error handler. (VFP9/SQL2008R2)

Some sites never see the behavior and others see it every second transaction. Some see it only occasionally.

The only commonality we've found in sites that encounter this problem is a WiFi network connection, and switching them to a wired connection seems to bring an end to the problem.

Has anyone else seen this?

 

[craigber]

Wifi can be fickle and VFP likes a constant connection. The best thing is to check that you still have a connection every time you access the database.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Dan Freeman]

Yeah, I know that. Of course, retrofitting that kind of checking into code that is in some cases 15 years old is no small trick.

The strange thing is that this error does NOT necessarily present when any sort of I/O is going on. In fact, the machine can be sitting idle.

 

[TamarGranor]

Dan-could the commonality be sitting on a form with a grid showing? I'm thinking that in a case like that, the grid is trying to make sure it can still talk to its data and losing the connection would mess things up.

Tamar

 

[DSummZZZ]

Are there any sort of timers?
I'm also wondering if during idle times some sort of internal VFP file handle may turn to something like .F. instead of integer.

Just a shot in the dark.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Olaf Doschke]

As the backend is SQL Server I wouldn't suspect network errors causing that error on idle machines, but maybe you also still have some DBFs on the network.

Can you narrow it down to certain forms, certain data or as Tamar suggests certain controls like the grid? I've seen lost controlsource errors slipping through error handling, more so with comboboxes, grids "just" go blank, but Wifi only can play a bigger role while you currently fetch data or with a DBF controlsource and not with a local cursor. Unless TEMP is misconfigured, so maybe check SYS(2023).

Bye, Olaf.

 

[Dan Freeman]

Thanks everyone!

Tamar, yes a grid is a likely culprit. There's one on nearly every form in this turkey. But Op/Op mismatch?

Dave, the first things I looked for were timers and menu SKIP FOR code. Nope.

Olaf, that's a good thought but the authors of this weren't creative enough to mess with TMPFILES. (I looked. <g>)

This is the first time I've heard of losing a controlsource bypassing error handling. Interesting. I guess I've just always had lucky connectivity. (Although they *are* all local cursors. Not a dbf in sight. It can happen anywhere in the app.)

 

[Olaf Doschke]

>This is the first time I've heard of losing a controlsource bypassing error handling

In more detail it happens mostly when the form having the lost controlsource is activated, so eg two forms in the same datasession are open, form2 closes a cursor needed by a combobox in form1. At that moment nothing happens, but when form1 is activated the unbound combobox throws this error and a messagebox appears, not the normal system error messagebox. I assume that's why it bypasses error handling.

Let me try to do a repro...

Bye, Olaf.

 

[Olaf Doschke]

This is demonstrating the effect of this specific Error slipping error handling:

PUBLIC oform1

oform1=NEWOBJECT("form1")
oform1.Show

On Error MessageBox("ON Error:"+Message())

DEFINE CLASS form1 AS form
	Height = 125
	Width = 223
	Caption = "Form1"
	Name = "Form1"

	ADD OBJECT combo1 AS combobox WITH ;
		RowSourceType = 6, ;
		RowSource = "curSelections.option", ;
		Height = 24, ;
		Left = 12, ;
		Style = 2, ;
		Top = 12, ;
		Width = 100, ;
		Name = "Combo1"

	ADD OBJECT command1 AS commandbutton WITH ;
		Top = 84, ;
		Left = 132, ;
		Height = 27, ;
		Width = 84, ;
		Caption = "Start Form2", ;
		Name = "Command1"

	PROCEDURE Load
		Create Cursor curSelections (option C(10))
		Insert into curSelections values ('option1')
		Insert into curSelections values ('option2')
	ENDPROC


	PROCEDURE command1.Click
		PUBLIC oform2
		oform2=NEWOBJECT("form2")
		oform2.Show
	EndProc
	
	Procedure Error()
	   LPARAMETERS nError, cMethod, nLine
	   MessageBox("Error EVENT:"+Message())
	EndProc 
ENDDEFINE

DEFINE CLASS form2 AS form
	Caption = "Form2"
	Name = "Form2"

	PROCEDURE Load
		Use in Select("curSelections")
		Use sdfhkjsdhflks
	ENDPROC
ENDDEFINE

The proof of the error handling doing it's work is the messagebox appearing when you start form2 by clicking on the command button of form1. Use sdfhkjsdhflks errors, as the file sdfhkjsdhflks.dbf doesn't exist, of course. Now the essential part: Close the form2 and only then, when form1 get's back the focus you get another error message, which has it's root in the rowsource cursor being closed ba form2.load already. This Messagebox does not come from the error handler, it neither starts with "ON Error:" nor "Error EVENT:". After you close that message, the combobox without rowsource is removed from form1.

It's not a operator/operand mismatch, so you may have to search for something completely different, but this sample shows there is in fact at least this error, which is slipping through error handling. And in another scenario the operator/operand mismatch might occur as a side effect.

Bye, Olaf.

 

[craigber]

10-15 year old code that's difficult to retrofit? Welcome to the real world.

It definitely sounds like a networking issue. There are several possibilities:

- The form is trying to refresh when it gets focus
- Hardware problems on the network. Anything from cables to connectors to routers
- SQL Server hasn't heard from the application for some time so it closes the connection

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog