...
So, then, what happens if my initial dictionary specification for my Dummy file:
[OriginalSpec.png]
Figure 1: Original DCT spec for DUMMY
proves to be inadequate. What if I find I need a second LONG?
Obviously, I add a second LONG to the dictionary:
[NewSpec.png]
Figure 2: New DCT spec for DUMMY
What if I later discover I need a few DECIMALs or two more STRINGs?
What happens when I change the dictionary and remake the app and open it? ErrorCode() 47 of course. Except that SQLite is quite friendly enough to tell me that in the way I'm used to:
[DummyErrorCode47.png]
Figure 3: ErrorCode() 47 as interpreted by SQLite
Further, suppose I can't wait for the expected SQLite support from Capesoft's FM3?
...
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
[Solution3.png]
Figure 3: Check DUMMY with standard ABC code
Try to open the file. If there is a LEVEL other than BENIGN, remove the file. Close it (probably not really necessary as it didn't really get OPENed) and let the FileManager or the RelationManager re-create it on the standard template OPEN.
...
That is to use a direct Clarion statements:
[Solution2.png]
Figure 4: Check DUMMY with standard Clarion code
This works fine. The final CLOSE is not actually necessary, the file wasn't OPENed, that's why there was an error.
...
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:
[Solution1.png]
Figure 5: Why not just …?
always REMOVE it before use and never worry about the specification?
...