Subject | Field Intercepts? |
---|---|
Author | gsndelphicoder |
Post date | 2007-12-18T17:14:14Z |
Hi All,
I am Branden Johnson. I am using Delphi 7, Firebird 1.5, IBO 4.6.A.
I'm not sure what to call what I'm trying to do? I save all of my
users in an AppUsers table with UserNbr(Integer) as the primary key.
They enter a UserID, Password, and other info when creating a new user
record. Once I've authenticated all of the data I create a firebird
user using the UserNbr as the firebird username/userid and the
password they entered. I have DateCreated(TimeStamp),
CreatedBy(Integer), DateModified(TimeStamp), and ModifiedBy(Integer)
fields in most of my tables, and I use triggers to set them. This way
I am storing the usernbr of the user who created and last modified the
record instead of the whole user id. I began doing this with web app
development where I am manually populating the grids and can
"intercept" the CreatedBy and ModifiedBy and display the UserID
instead of the usernbr, which i meaningless to the users.
However, I have began a desktop app where I am linking/data sourcing a
db grid to an active TIBOQuery. This automatically displays the
meaningless UserNbr field in the grid. I am looking for an efficient
way of doing this same kind of "intercepting" at the query or
connection level to change the CreatedBy and Modified by fields to
VarChar15 and display the UserID. Is there an easy way of doing this?
I know that I could created calculated fields on every query and
write code to handle them but I would like to not have to create
persistent fields on every query as DB structure changes will probably
be pretty frequent with the way my client is wanting to develop this
app (small sections at a time without spending time to layout the
entire design ahead of time). If this will not work I will probably
just go back and change the CreatedBy and ModifiedBy fields to
VarChar(15) like the UserID field in the AppUsers table and create the
firebird user with the UserID instead of the UserNbr. Thats not the
optimal way to save the users info but may be necessary to avoid the
persistent fields drawback?
If anyone has any suggestions I would greatly appreciate it!!!
Thanks all,
Branden Johnson
I am Branden Johnson. I am using Delphi 7, Firebird 1.5, IBO 4.6.A.
I'm not sure what to call what I'm trying to do? I save all of my
users in an AppUsers table with UserNbr(Integer) as the primary key.
They enter a UserID, Password, and other info when creating a new user
record. Once I've authenticated all of the data I create a firebird
user using the UserNbr as the firebird username/userid and the
password they entered. I have DateCreated(TimeStamp),
CreatedBy(Integer), DateModified(TimeStamp), and ModifiedBy(Integer)
fields in most of my tables, and I use triggers to set them. This way
I am storing the usernbr of the user who created and last modified the
record instead of the whole user id. I began doing this with web app
development where I am manually populating the grids and can
"intercept" the CreatedBy and ModifiedBy and display the UserID
instead of the usernbr, which i meaningless to the users.
However, I have began a desktop app where I am linking/data sourcing a
db grid to an active TIBOQuery. This automatically displays the
meaningless UserNbr field in the grid. I am looking for an efficient
way of doing this same kind of "intercepting" at the query or
connection level to change the CreatedBy and Modified by fields to
VarChar15 and display the UserID. Is there an easy way of doing this?
I know that I could created calculated fields on every query and
write code to handle them but I would like to not have to create
persistent fields on every query as DB structure changes will probably
be pretty frequent with the way my client is wanting to develop this
app (small sections at a time without spending time to layout the
entire design ahead of time). If this will not work I will probably
just go back and change the CreatedBy and ModifiedBy fields to
VarChar(15) like the UserID field in the AppUsers table and create the
firebird user with the UserID instead of the UserNbr. Thats not the
optimal way to save the users info but may be necessary to avoid the
persistent fields drawback?
If anyone has any suggestions I would greatly appreciate it!!!
Thanks all,
Branden Johnson