> At 08:41 AM 8/28/04, Dick Applebaum wrote:
> >If you store alerts in the db, you should set uo a separate table for
> >alerts say
> >
> >AlertID��PK
> >AlertUserID FK��references(User, UserID)
>
> Thanks for your suggestion. A separate table seems like a good idea.
> The
> AlertID field would be a PK (Primary Key). What kind of key is FK?
> (I'm
> using Access, would that be a "link" in Access?).
Foreign Key -- I think Access supports Foreign Keys
> In this scenario, when I populate the "Alerts" table with CF, how
> would the
> AlertUserID field be populated? Should I use INSERT to put that info
> there,
> or should it come from the original USERS table using the built-in
> relationship?
>
I would do this: variable
Given you an alert for
-- avalid UserID stored variable NewAlertUserID
--the message stored in variable NewAlertMessage
Assume that AlertID is auto-number (generated by the system)
Insert into table Alert
(AlertUserID, AlertDateTime, AlertRead, AlertMessage)
values(#NewAlertUserID#, '#CreateDateTine(Now())#', 0,
'#NewAletMessage#')
I can't suggest too strongly that you NOT use MS-Access -- it just
isn't designed for this purpose.
There are many other options (MySQL, PostgreSQL, Cloudscape, etc.) that
are better faster, more robust, more reliable and free open-source
Dick
> Roberto
>
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
