Subject | Re: [firebird-support] system tables - second attempt. |
---|---|
Author | Geoff Worboys |
Post date | 2005-04-16T01:23:57Z |
> However, I was trying to avoid having to parse each field(As you know) if you are talking to a dialect 3 database then
> name character by character checking for a space or lower
> case character. It would be so much easier to check a flag,
> or some other value in the system tables. Just wondering if
> that existed anywhere in the system tables.
quoted names are possible - BUT there is no "flag" to indicate
whether a field was originally created with quotes or not.
"THIS" is identical to This ThIs and this in terms of
how it is stored and interpretted by FB. However:
"FROM" is a valid identifier whereas FROM is a keyword and
cannot be used as an identifier.
"1ST" is a valid identifier whereas 1ST would cause an
error.
Later you say:
> I have a procedure which will produce a runnable script toThere are a number of ways to approach the problem...
> create auxillary tables and triggers to audit data modification
> on the original tables. Yes, I suppose I could do this
> manually for every table in every database,
If your database policy is to never use quotes then (obviously)
you should never need to use quotes.
If your database policy allows the use of quoted identifiers
then you have (at least) two options...
* You could try to be smart and determine whether the characters
in the name will require quoting - just remember that the first
character has different requirements to the rest (eg: "1ST").
If you follow this approach you also need a list of keywords to
check whether quotes are needed regardless of the validity of
the characters (eg: "FIRST").
This can be somewhat arduous to code but having seen it in
action (in IBObjects) it works pretty well.
* Quote everything. There is no harm in creating trigger and
stored procedure code that uses redundant quotes (eg: "THIS").
Since the code is automatically produced who cares whether it
looks exactly like what the user would have written. It also
has the advantage of "future proofing" the SQL code for new
versions of FB that may introduce new keywords. (Take a look
at some of the new keywords that came with v1 and v1.5 and
you can see the potential hazards.)
There is also another way to approach your particular
requirement. Use something already written for the task. See
IBLogManager at http://www.upscene.com/
--
Geoff Worboys
Telesis Computing