Dummy Tables

[Bob Elliott]

I have a question? What is the purpose in some of the sample application that contain tables that are just "DUMMY TABLES". This may sound like a dumb question but just learning!

[Michael Humby]

RE: Dummy Tables

One of the main reasons but there must be many more. If you are running scripts that require your application tables to be closed such as index building, deleting $$ files you can run the script from a form based on the dummy table that contains no important data.

Michael

[Jeff Moses]

RE: Dummy Tables

Bob, you can also use dummy tables to link misc forms to such as a main menu, utility screen and so on.
Jeff

[csda1]

RE: Dummy Tables

I believe the usage of "Dummy" tables is wrong!!!!

I prefer to think of them as "Database Usage challenged"

Actually, though, I use to refer to them as DUMMY.DBF when using A4, but this often led to disaster as stupid...correction, "Intellectully Challenged" users would delete them thinking they were un-important (as in a Temporary DBF).

Thus, since moving to A5, I have tended to call these tables things like APP.DBF, MAINMENU.DBF, MENU.DBF etc. I almost always create a one field table with 1 record (1 record takes care of some cases where a 0 record table may be treated a bit differently)

The importance of these tables is that while you have them open, since they don't connect to any tables that have data in them, and have a minimal set of forms and similar associated with them, they do not lock up other tables for operation that require exclusive use. If you return to that table, form, etc when not performing other functions, you minimize corruptions to your real data tables in case of a workstation or network crash.

In a similar fashion, I always create Temporary files with a name starting with TEMP so that the file is easy to find and to delete. When possible, place the Temp files in the user's private directory and delete when done with them. If they need to be shared with other users, then create it in the Master (ADB's) path of the database.

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[Jeff Moses]

RE: Dummy Tables

Ira,
Not to wake up a sleeping dog, but if the user (who should never know what the table names are to begin with because the app was written using MAXIMIZED forms and access to the control panel does not exist), it would not matter to anyone but the programmer if the table was named dummy? I will always love you Ira, even when I oppose your posted views of such conviction! Opposition is a great way learn.
Your friend always,
Jeff

[csda1]

RE: Dummy Tables

Jeff,

That would be true, IF, and only IF, Alpha was the only way of accessing your files. If you have dialog boxes that allow a file selection, then a user could potentially select any directory, including your database directory (which is often a default - bad, BAD choice) to say, export some data.

One way is to set the default someplace else (My Documents is a good useless choice, remembering their last chosen directory is better - that's what I do) and disallow the choice of the database directory by comparing it to the A5.Get_path(), A5.get_master_path() and then making them go reselect it.

And then there is something called DOS and Windows Explorer. When a user has only 50k free space and starts clearing out his hard disk, they just love to delete anything that looks unimportant to them. (We could turn this thread into a User-bashing thread, but I don't really want to go there.)

Regards,

Ira J. Perlow
Computer Systems Design & Associates
[email protected]

[whanigsberg]

RE: Dummy Tables

Hi Ira,

I don't believe user bashing could be confined to a single thread. More likely it would need its own forum!

Bill

[CALocklin]

RE: Dummy Tables

and disallow the choice of the database directory by comparing it to the A5.Get_path(), A5.get_master_path() and then making them go reselect it.

I LOVE IT! Thanks Ira. I never thought of this before but it will definitely be used in the future.

Cal