Odd behaviour of a cursor

[alvechurchdata]

This has been running for five years and failed today.

I create a cursor in a form's Init event and use it to drive a grid. Elsewhere on the form there's a GO TOP. Today that failed with an "Error 12 - Variable not found".

For some reason Fox had decided this morning to generate the cursor by filtering the base table instead of creating a temporary file. The GO TOP exists in a method which can't see the ClientID used in the filter expression so the system falls over.

It was easy to add a NOFILTER clause once I'd tracked down what was happening but can anyone explain what's going on in Fox's tiny vulpine mind? After five years of smooth running it decides to change the way it generates a cursor. Why me?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[bborissov]

Maybe you add some additiona indexes which made query to be fully optimizable, or add some more memory.
Once NOFILTER clause was introduced, I always use it in my queries

Borislav Borissov
VFP9 SP1, SQL Server 2000/2005.
MVP VFP

 

[alvechurchdata]

Maybe you add some additiona indexes which made query to be fully optimizable, or add some more memory.

I had made some changes to another form in the system but nothing that seems to relate to this particular form or the tables it uses. I don't think it can be memory because three users reported the problem at once this morning - unless they've upgraded the server somehow and not told me.

Once NOFILTER clause was introduced, I always use it in my queries

Me too but I really don't want to have to go back and retrofit it to old jobs. Mainly because nobody would pay me to do it.<g>

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[TamarGranor]

Maybe SET DELETED was different? Or SET ANSI?

Tamar

 

[ramani]

Hi

Is it that you are using code to ceate the new form as against the visual form designer ?

In the past I have noticed, that when forms are created by code and the forms base class themselves are made out of code in a prg as against vcx, the first form gets instantiated correctly and the second form creates problem.

This is owing to the cacheing of the code in memory with same class name. Though i cleared the memory, some issues which I dont remember exactly, kept troubling me and i finally fixed in a different way..

If i remember correctly.. let us take.. formbase1-> formbase2-> formbase3 etc each building on the previous class with some etc. functionality.. and if we create one form on formbase3 and then call from that another search or such form again made on the same formbase3 throws errors. However, if it called on the formbase3a.. just an extension of formbase3 with no new add on code.. it worked fine.

So, if you had made the forms on code.. and the new form had any such common same base class.. the issue may be coming up. I could not solve the problem.. but used an exteended subclass in such cases.

Anyway I often make based on gui forms and that project on code was a sample one to see any differnce existed. I dont follow that pattern owing to the extra load of work. The only advantage is that I can control the VFPs pesky directory bindings on the form classes whenever we copy the forms from one project to another and the copy keep directing to original class locations, while the class itself would have been copied to the newer directory. The vcx need to be hacked for such things.. while a code goes with relative directory refernces and so predictable. That is a whole different discussion anyway !.

____________________________________________
ramani - (Subramanian.G)

http://winnersoft.coolfreepages.com/

 

[alvechurchdata]

Is it that you are using code to ceate the new form[\quote]

That was the great puzzle, there was no new form. The bug just popped up in a form that had been sitting there unchanged for some months, if not years.

The only change I've made recently was on a report in another area of the app and I think Tamar might have shown a chink of light here. I had had to set ANSI ON because the report was picking up some values that it shouldn't have done. In fact I noticed that SET ANSI had been missed out of the setup code for the whole app so I added a SET ANSI ON into main.prg. Could this have changed Fox's optimisation strategy?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[TamarGranor]

SET ANSI ON changes the way VFP matches strings in SQL commands, so it can change both optimization and results.

Tamar