Ajit Dixit
|
| Posted: 06/14/2001, 7:10 AM |
|
HI,
Kindly consider following points for your considerations.
1. At present codecharge facilitates unique identifier for a given field,
but there is no facility for defining uniqueness on multiple fields
This is basically a uniqueness on combination of multiple fields.
This is generally done by unique index in database .
Can we have facility to define uniqueness on the basis of multiple
fields?
2. Also where primary key is on the basis of multiple fields codecharge
have no facility of detection and user is exposed to the error thrown by
browser
Can we have facility for error trapping in codecharge and giving
user elegant interface
3. Also while defining the relationship at present codecharge allows
definition only on the basis of primary key with one field.
It should be possible to define relationships based on multiple
fields (keys).
I hope codecharge team would consider these suggessions
Thanks
Ajit Dixit
|
|
|
 |
Dr. Scott R. Senay
|
| Posted: 06/14/2001, 10:55 AM |
|
Ajit some of what you are asking for here you DO NOT actually want. I don't
mean to get off on a rant here but,
In "1" below you are asking for a compound key, which is retrograde DB
design, have your DB re-work the architecture BEFORE you start building with
CC and assorted tools. If you already have a DB that uses compound keys you
would be well served to do a redesign BEFORE you invest in building new
systems around it. Regardless of your architecture, be it RDBMS or object
oriented, you want to keep a certain level of normalization in your designs,
it will save you MONTHS of work.
In "2" below you again are probably going to be on you own here and have to
invest months building custom code to support compound keys, these ARE NOT
the norm for the industry at large and for administrative and coding use
should be avoided like the plague!
In "3" below you again are probably going to be on your own here... Seems
like a theme in your requests all based on compound keys... Are you working
on OLD mainframe or micro based flat file data? You are going to be forced
to normalize this to get any work done... Otherwise you are going to add
MONTHS to development and probably a year to overall project rollout and
eventual success...
Are you working with old insurance company data? Sure sounds like it! What
you will need to do is add a hidden field or two to each form, use a "Before
Show" event to populate the hidden field, then in a "Before Insert" put
together the information that needs to be written in the form it needs to be
written. If you want to be using multiple fields from multiple tables
you'll need to use a "Before Show" to use the dlookup() function on a number
of tables to build your compound keys. In any case, your making SO MUCH
more owrk for yourself that you may actually be better off coding the whole
thing from scratch...
That's just my opinion, I could be wrong...
Mind you my opinion is based on more than two decades as a DBA and RDBMS
designer and developer... I've built systems for some of the largest
companies in the world and NONE of them use non-normalized flat files any
longer.
Scott...
Ajit Dixit <aldixit@vsnl.com> wrote in message
news:9gagl1$3ip$1@mail.tankhill.com...
> HI,
>
> Kindly consider following points for your considerations.
>
> 1. At present codecharge facilitates unique identifier for a given
field,
> but there is no facility for defining uniqueness on multiple fields
> This is basically a uniqueness on combination of multiple fields.
> This is generally done by unique index in database .
> Can we have facility to define uniqueness on the basis of multiple
> fields?
>
> 2. Also where primary key is on the basis of multiple fields codecharge
> have no facility of detection and user is exposed to the error thrown by
> browser
> Can we have facility for error trapping in codecharge and giving
> user elegant interface
>
> 3. Also while defining the relationship at present codecharge allows
> definition only on the basis of primary key with one field.
> It should be possible to define relationships based on multiple
> fields (keys).
>
>
> I hope codecharge team would consider these suggessions
>
>
> Thanks
>
>
> Ajit Dixit
>
>
|
|
|
|
|
