Version: 1.00.00 - last update: Saturday, September 6, 2014

---

This Thread is About Some Native VFP Cursor Behavior

I worked together with a VFP colleague for two years; her name was Madlen. Madlen discovered a remarkable VFP feature while debugging some weird side effects, that were produced by exact that 'feature'. Thus, it is not my discovery, but let's give honor to whom honor is due. Obviously, Madlen don't find enough time to share here new knowledge with the VFP community beside here daily work. Madlen allowed me liberally to post about her findings on this blog.

I have to state that this VFP 'feature' was absolutely new to me, and all of my former colleagues, too. That's why I supposed that even today scarcely anybody knows about it.

The Madlen Effect

Madlen discovered that, if you create a temporary cursor using an array-based schema definition stemming from a schema array created using VFP's AFields(), you better have to be very careful! Madlen used one of the DBC-based 'master' tables as her schema source, just as we all would have done it. Alas, in this particular case, the schema source table had some triggers attached. Naturally, these trigger expressions were caught by VFP's AFIELDS() function, and got transferred into Madlen's schema definition array. From there they were applied to the new temporary cursor. What could I say, I think you might already have guessed it: The trigger were alive in the newly created cursor, too!

Such an undocumented(?) side-effect may cause you a lot of headache! Not so much if you incidentally close the trigger procedure, which would raise a traceable exception immediately, but in cases you are not aware of the triggered behavior at all, wondering about 'strange' values appearing in you temporary cursor, obviously without any good reason…

^{I know, how that hurts…}

I'm currently refactoring my top level modules' asynchronous message queues to incorporate VFP Cursors! What a show: Semi-persistent message queue stacks that don't pollute my DBC, but behave like the Big DBC-Bros do – somehow slick ;-)

<to be continued…>

---