by Unlicensed Unknown user
Last time I figured out how to make The Dummy Table Technique work. Using this technique is a bit different than when using it with full blown SQL (i.e., the kind with a dedicated engine). Not only do I need to declare the dummy table in my dictionary but I have to ensure that the SQLite table physically exists.
So, then, what happens if my initial dictionary specification for my Dummy file:
Figure 1: Original DCT spec for DUMMY
...
Obviously, I add a second LONG to the dictionary:
Figure 2: New DCT spec for DUMMY
...
What happens when I change the dictionary and remake the app and open it? ErrorCode() 47 of course. Except that SQLite is not quite friendly enough to tell me that in the way I'm used to:
Figure 3: ErrorCode() 47 as interpreted by SQLite
...
Or I could guess at how many variables, and what types, I might need. And then pray for the best. But, here in the trenches, few believe in the efficacy of prayer.
The Easy Solution
Figure 3: Check DUMMY with standard ABC code
...
That is to use a direct Clarion statements:
Figure 4: Check DUMMY with standard Clarion code
...
But I never actually use the file. There is never any i/o. All The Dummy Table Technique needs is the file BUFFER. Since the physical file is never actually used, why not just:
Figure 5: Why not just …?
...