Create table

[AutoTraker]

Here is something that shouldn't work that does.
The database name is created use fUnique and
we use a macro in our create table command.
But note the syntax. I would expect it to fail
since the database name does not match the
name "EMAIL" in the body of the command.
Is this one of those "Good" bugs?

-
Rich...
www.autotraker.com
AutoTraker Inc.

Demo CD disks are available free to any Automotive repair shop.
We are one of the top Automotive POS programs in the country.
AutoTraker is written 90% in dBase version 5.7 and works on
all Windows platforms. Finder fee for referrals and commission
on all sales. Contact our office for info on our dealer program.





databaseName = fUnique()
? databaseName
create table "&dataBaseName." ( ;
EMAIL.'LDELETE' BOOLEAN,;
EMAIL.'REPLY' BOOLEAN,;
EMAIL.'JUNK' BOOLEAN,;
EMAIL.'GET_BODY' BOOLEAN,;
EMAIL.'FROM' CHAR(60),;
EMAIL.'SUBJECT' CHAR(128),;
EMAIL.'TO' BLOB,;
EMAIL.'ACCOUNT' CHAR(60))
? file ( "&dataBaseName."+".dbf" )

[Ken Mayer [dBASE, Inc.]]

Post by AutoTraker
Here is something that shouldn't work that does.
The database name is created use fUnique and
we use a macro in our create table command.
But note the syntax. I would expect it to fail
since the database name does not match the
name "EMAIL" in the body of the command.
Is this one of those "Good" bugs?

Odd. One suggestion to avoid confusion in your code: don't use the
word "database" when referring to a table. I know that in the old DOS
days this term was used in the manuals, but ... in the Windows
environment, particularly in the 32-bit versions of dBASE, there's a
database *object* which refers to a BDE Alias or a SQL database. The
DOS manuals were wrong in using the term "database" to refer to a
single table ... always were. </lecture> <g>

Anyway, I'll note this for R&D. It's a weird one, and fairly benign,
but I wouldn't write code that relied on this bug because if/when it
gets fixed your code will break ...

I have entered QAID: 4346


Ken
---
Ken Mayer [dBASE, Inc.]
** Please respond ONLY in the newsgroups **

"Think OOP"

dBASE, Inc. website: http://www.dbase.com

[Todd Kreuter]

Post by Ken Mayer [dBASE, Inc.]
Anyway, I'll note this for R&D. It's a weird one, and fairly benign,
but I wouldn't write code that relied on this bug because if/when it
gets fixed your code will break ...
I have entered QAID: 4346

I use this all the time. Its easier when creating tables with variable
names and needing to delimit fields. I normally use 'T' as the table
reference for all tables created. The name of the table reference is
meaningless. As a matter of fact you could do something like:

create table "Customer" (;
'A'.'ID' Char(10),;
'B'.'Name' Char(30),;
'C'.'Region' Char(4))

Create table should not care what the table reference is because it can
only create one table at a time.

[Ken Mayer [dBASE, Inc.]]

<lecture response>
Yes, I most certainly heed your warning, although the use of the variable
"databaseName" was for demonstation purposes in that code sniblet and
not for any production work. I quess it did seem odd to see a line like
create table "&dataBaseName."
I got past the confusion between tables that are called databases that are
in reality tables and not databases at all, long ago. </lecture response>

Heh. Well, that one does trap people and it is confusing, since the
original manuals called tables databases ... so when database objects
got in there it really messed a bunch of folk up, and still does.

Ken
---
Ken Mayer [dBASE, Inc.]
** Please respond ONLY in the newsgroups **

"Think OOP"

dBASE, Inc. website: http://www.dbase.com

[O. D. Williams]

On Fri, 11 Jul 2003 13:21:03 -0700, "Ken Mayer [dBASE, Inc.]"

Post by Ken Mayer [dBASE, Inc.]
Heh. Well, that one does trap people and it is confusing, since the
original manuals called tables databases ... so when database objects
got in there it really messed a bunch of folk up, and still does.
Ken
---

I noticed a great increase in the sales of Prozac about the same
time! Coincidence? I think NOT! <G>

-O.D.W..-
The O. D. Williams philosophy of programming.
Why there is ALWAYS one more bug.
1. Debuging code is always much harder than writing it.
2. Therefore, if your code is as clever as you are capable of
making it, you are, by definition, inadequate to debug it.