|
|
Posted by pbd22 on 11/08/06 18:03
thank you blvandeb@yahoo.com!
that was it. the recordID idea was spot on.
thanks a ton!
pbd22 wrote:
> EXPECTED RESULTS:
>
> There should "always" be one row that matches the update statement
> based on the
> public_name column of the EditProfile table, which is unique. This is
> an Add User
> page.
>
> The user requests an add, which leaves a 0 in the add_status column.
> When the
> current user clicks on "Add User", the update statement is supposed to
> change
> add_status from 0 (pending) to 1 (accepted). The select statement in
> the where
> clause is necessary because we need to know the public_name of the
> requesting
> user so one unique row is returned.
>
> so, in AddList,
>
> email_address describes the user that did the requesting
> add_email describes the user that is acting upon the request (current
> user)
> add_status describes the status of the request (pending/accepted)
>
> and, in EditProfile,
>
> public_name describes the unique name of the user that did the
> requesting
>
> *************************************************************************************************
> THE INDENDED RESULTS of this code is to change the row with the current
> user's email address (add_email) and the requesting user's public name
> (public_name)
> from 0 to 1.
> *************************************************************************************************
>
> below is the pseudo code of what i am attempting:
>
> update addlist
> set add_status to accepted (1)
> where add_status is pending (0)
> and do this where the requesting user's public name is 'Wolfie'
> (public_name)
> and the current user's email address is 'mags23@heaven.net' (add_email)
Navigation:
[Reply to this message]
|