Re: Saving a constant into the Oracle schema?

"Hans Forbrich" <forbrich_at_telusplanet.net> wrote in message news:3E8B16BA.96A92789_at_telusplanet.net...
> The way you ask this question, I wonder whether we are using the same
> definition of 'database' or 'schema'.
>
> The only situation similar to yours that I can envision makes me believe
you
> say "database" when you mean "table". I have noted that many programmers
with
> VB experience and especially those with MS-Access experience will use this
> definition. The following assumes you mean "table" ...
>
> If you are trying to get a default value into a column you may want to
consider
> using the column's 'default' capability. If you are need to change that
> default value once a year, make it part of your annual procedure to alter
the
> table/column default setting. That would totally eliminate programming
effort.
>
> HTH
> /Hans

Actually, all of my VB and VC++ experience has been with Oracle. I had to touch somebody's Access code once; it was not entertaining! ;) (It was an old application, but I don't know why they designed for Access when we had an Oracle 7.3 server. I remember when he asked me for the filename of the database, so he could link to it for account numbers/names! I had to explain a tablespace to him; he wound up importing the account information from a sqlplus file I generated. But I digress...)

So, I do mean "database" when I say "database". :) For the schema inside the database, I have multiple tables, procedures, triggers, and sequences defined under one main "user". These objects are referenced through programs (VB EXE's and VC++ .DLL's and IIS/ASP), mainly using OLE DB, with some ADO from VB. The DLL and the IIS/ASP are tied together; the DLL feeds off the value from ASP. However, when I do database operations that are not from within ASP, I've had to either hardcode the value, or pull it from the Windows registry. I'd like to eliminate all this inconsistency, and store the value once, inside Oracle. Then -everything- could reference it- the internet server, the vb programs, the .DLL file, report queries, etc. Changing it for the next year would be easy, since I would just have to change one central area.

The columns in the tables that do reference this constant variable have been set up as "not null" with no default values. These columns, with the exception of one or two occurances, are being set by triggers or procedures. I actually wanted to avoid setting a default value for these columns, in order to keep this value more central, and to avoid altering the tables every year. I think one of the bothers with this value is that it is part of the primary key; this column exists in every table in the schema!

Thanks,

-Thomas Received on Wed Apr 02 2003 - 12:24:12 CST