Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

by Unlicensed user 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:

Image RemovedImage Added

Figure 1: Original DCT spec for DUMMY

...

Obviously, I add a second LONG to the dictionary:

Image RemovedImage Added

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 quite not quite friendly enough to tell me that in the way I'm used to:

Image RemovedImage Added

Figure 3: ErrorCode() 47 as interpreted by SQLite

...

Truth? That's hard. It means checking every filter, every totaling op, everything to determine the number of variables and data types and number of variables per data type that I need. Then I have to accurately guess what I may be asked for in the future.

I could “just” declare a bunch of CStrings and let Clarion convert data for me. Of course, any numeric is quite likely to need to be FORMATted so that leading/trailing zeros are where they're expected to be.

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

Image RemovedImage Added

Figure 3: Check DUMMY with standard ABC code

...

The only issue I had with this is that it didn't work. Both

Access:DUMMY.Open

and

Relate:DUMMY.Open

returned the error window shown in Figure 1.

...

That is to use a direct Clarion statements:

Image RemovedImage Added

Figure 4: Check DUMMY with standard Clarion code

This works fine. The final CLOSE is not actually necessary, if there was an error, the file wasn't OPENed, that's why there was an error. But, if there wasn't an error, the CLOSE is necessary. It probably should be wrapped in some conditional code.

The standard template-generated opening of the file will create it. So, everything is copacetic.

...

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:

Image RemovedImage Added

Figure 5: Why not just …?

...