Looking for some direction here.

I have a form that collects user data. When an employee opens the form
they enter in all of the user data for an account, however the account can
have multiple users so the employee has the option to "Enter another user
for this account" and they can do this for as many users as the account
holds.

What I can't figure out is how to store the first set of user details, have
the blank form come up again, store the second set of user details, have the
blank for come up again, insert a third set of details and then have all
three sets submit to the database at the same time.

Did the make sense?

Would using a session work to store all this user data for a single
submission?

On 3/20/07, Dan Shirah <EMAIL REMOVED> wrote:
> Looking for some direction here.
>
> I have a form that collects user data. When an employee opens the form
> they enter in all of the user data for an account, however the account can
> have multiple users so the employee has the option to "Enter another user
> for this account" and they can do this for as many users as the account
> holds.
>
> What I can't figure out is how to store the first set of user details, have
> the blank form come up again, store the second set of user details, have the
> blank for come up again, insert a third set of details and then have all
> three sets submit to the database at the same time.
>
> Did the make sense?
>
> Would using a session work to store all this user data for a single
> submission?

Sure you could add an array item in the session for each submit, but i
would just recommend to add each item just after submitting.
Because if they guy is adding a lot of users, and his internet stops
working for example, all data is lost when using sessions, having it
already stored in the database would be nice then

Tijnema
>

Dan Shirah wrote:
> Looking for some direction here.
>
> I have a form that collects user data. When an employee opens the form
> they enter in all of the user data for an account, however the account can
> have multiple users so the employee has the option to "Enter another user
> for this account" and they can do this for as many users as the account
> holds.
>
> What I can't figure out is how to store the first set of user details, have
> the blank form come up again, store the second set of user details, have
> the
> blank for come up again, insert a third set of details and then have all
> three sets submit to the database at the same time.
>
> Did the make sense?
>
> Would using a session work to store all this user data for a single
> submission?

Hi Dan,

Although sessions look appealing, you may find that users use the "Back"
button on their browser to return to the previous step, and sessions
won't allow this to work properly.

If you really wish to wait until the third user before saving any of
them, then I would use hidden form fields with the data from the
previous entries.

However, if I were in your shoes, I would probably set up the form to
create the account and save immediately to the database, then add the
other users one at a time. The end of a request is the perfect time to
save data, as long as you allow editing of the details. Again, expect
users to use "Back" and make sure that if you do save using a numeric
primary key, that you pre-generate it so that it will still be present
if the user clicks "Back." This way, you can safely allow editing of
the data by just using an UPDATE query rather than INSERT if the data
already exists.

Also, if you are taking sensitive data, be sure this web form is either
on a firewalled intranet or some other security precautions so that you
don't expose SSNs to the public hacker community.

Hope this helps,
Greg
--
Experience the revolution, buy the PEAR Installer Manifesto
http://www.packtpub.com/book/PEAR-installer

In my database I have two tables. One table stores all of the account
information, the other table stores all of the user information.

Table 1
account_id - is the primary key and is unique to each account

Table 2
user_id - is the primary key and is unique to each user
account_id - will be set to whatever the account id is in Table 1

You are suggesting that when they click "Enter another user for this
account" that I save the account/user information to the database and then
when the form refreshes have something like:

if (!isset($_POST['submit']))

to determine if this is a continuance of a multiple user submission?

And then I should select the account_id that was just created? Using
something like:

SELECT scope_identity() FROM accounts

Or is there a better way to determine the recently created account_id so I
can use it for any other user data that is created for this account?


On 3/20/07, Greg Beaver <EMAIL REMOVED> wrote:
>
> Dan Shirah wrote:
> > Looking for some direction here.
> >
> > I have a form that collects user data. When an employee opens the form
> > they enter in all of the user data for an account, however the account
> can
> > have multiple users so the employee has the option to "Enter another
> user
> > for this account" and they can do this for as many users as the account
> > holds.
> >
> > What I can't figure out is how to store the first set of user details,
> have
> > the blank form come up again, store the second set of user details, have
> > the
> > blank for come up again, insert a third set of details and then have all
> > three sets submit to the database at the same time.
> >
> > Did the make sense?
> >
> > Would using a session work to store all this user data for a single
> > submission?
>
> Hi Dan,
>
> Although sessions look appealing, you may find that users use the "Back"
> button on their browser to return to the previous step, and sessions
> won't allow this to work properly.
>
> If you really wish to wait until the third user before saving any of
> them, then I would use hidden form fields with the data from the
> previous entries.
>
> However, if I were in your shoes, I would probably set up the form to
> create the account and save immediately to the database, then add the
> other users one at a time. The end of a request is the perfect time to
> save data, as long as you allow editing of the details. Again, expect
> users to use "Back" and make sure that if you do save using a numeric
> primary key, that you pre-generate it so that it will still be present
> if the user clicks "Back." This way, you can safely allow editing of
> the data by just using an UPDATE query rather than INSERT if the data
> already exists.
>
> Also, if you are taking sensitive data, be sure this web form is either
> on a firewalled intranet or some other security precautions so that you
> don't expose SSNs to the public hacker community.
>
> Hope this helps,
> Greg
> --
> Experience the revolution, buy the PEAR Installer Manifesto
> http://www.packtpub.com/book/PEAR-installer
>

Dan Shirah wrote:
> In my database I have two tables. One table stores all of the account
> information, the other table stores all of the user information.
>
> Table 1
> account_id - is the primary key and is unique to each account
>
> Table 2
> user_id - is the primary key and is unique to each user
> account_id - will be set to whatever the account id is in Table 1
>
> You are suggesting that when they click "Enter another user for this
> account" that I save the account/user information to the database and
> then when the form refreshes have something like:
>
> if (!isset($_POST['submit']))
>
> to determine if this is a continuance of a multiple user submission?
>
> And then I should select the account_id that was just created? Using
> something like:
>
> SELECT scope_identity() FROM accounts
>
> Or is there a better way to determine the recently created account_id so
> I can use it for any other user data that is created for this account?

Hi Dan,

Yes, there is a better way. What you have described is probably more
complex than you need, and requires more clicking by the user than is
necessary.

First of all, do you allow multiple accounts for the same user? If so,
you're going to run into troubles with querying later on with the
current data schema. Generally, when I'm working with inter-linking
data like you describe, I construct it as:

Table 1 account_info:
account information
account_id

Table 2 user_info:
user information
user_id

Table 3 account_link:
user_id
account_id

This way, you never duplicate user information, and it is very easy to
link or unlink users from accounts.

In the web form, if you allow adding up to 3 users maximum, why not just
put all of the input on a single page?

In addition, you might consider either using an AJAX-based dropdown, or
populating a static dropdown with previous users (***uming the list of
users is short), so that if a previous user is entered into the account,
that name can be used.

In addition, if you have all 3 users on one page, you can validate them
all at once, check for accidental duplicates (i.e. if a name matches an
existing user, bring up the form and ask if they intend to create a new
user, or wish to use the existing one).

There are lots of options. If you do decide to do a multi-page form,
with database submit right at the last step, there is an example of how
I've done this in the code for pear.php.net's election creation
interface, at
http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup.


This code makes use of simple php-based templates found in:

http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup

Hope this helps,
Greg
--
Experience the revolution, buy the PEAR Installer Manifesto
http://www.packtpub.com/book/PEAR-installer

I had thought about having the multiple submissions on a single form, but
with the amount of user information that is collected and the variable
amount of users that may need to be entered this method would not be ideal.
(A single form that you have to scroll down a far way and the potential to
not have enough user inputs is what prevents this method from being used)

Each account is unique. It is possible that the same user could be on
multiple accounts, therefore the account will be tied to the user each time.

No account_id will be duplicated, but the user table can hold the same user
multiple times tied to different accounts.


On 3/20/07, Greg Beaver <EMAIL REMOVED> wrote:
>
> Dan Shirah wrote:
> > In my database I have two tables. One table stores all of the account
> > information, the other table stores all of the user information.
> >
> > Table 1
> > account_id - is the primary key and is unique to each account
> >
> > Table 2
> > user_id - is the primary key and is unique to each user
> > account_id - will be set to whatever the account id is in Table 1
> >
> > You are suggesting that when they click "Enter another user for this
> > account" that I save the account/user information to the database and
> > then when the form refreshes have something like:
> >
> > if (!isset($_POST['submit']))
> >
> > to determine if this is a continuance of a multiple user submission?
> >
> > And then I should select the account_id that was just created? Using
> > something like:
> >
> > SELECT scope_identity() FROM accounts
> >
> > Or is there a better way to determine the recently created account_id so
> > I can use it for any other user data that is created for this account?
>
> Hi Dan,
>
> Yes, there is a better way. What you have described is probably more
> complex than you need, and requires more clicking by the user than is
> necessary.
>
> First of all, do you allow multiple accounts for the same user? If so,
> you're going to run into troubles with querying later on with the
> current data schema. Generally, when I'm working with inter-linking
> data like you describe, I construct it as:
>
> Table 1 account_info:
> account information
> account_id
>
> Table 2 user_info:
> user information
> user_id
>
> Table 3 account_link:
> user_id
> account_id
>
> This way, you never duplicate user information, and it is very easy to
> link or unlink users from accounts.
>
> In the web form, if you allow adding up to 3 users maximum, why not just
> put all of the input on a single page?
>
>

HTML Code:

> Account information:
>
> Form Field 1: ________
> ...
>
> User #1 (required)
>
> Name: _____
> ...
>
> User #2 (optional)
>
> Name: _____
> ...
>
> User #3 (optional)
>
> Name: _____
> ...
>

>
> In addition, you might consider either using an AJAX-based dropdown, or
> populating a static dropdown with previous users (***uming the list of
> users is short), so that if a previous user is entered into the account,
> that name can be used.
>
> In addition, if you have all 3 users on one page, you can validate them
> all at once, check for accidental duplicates (i.e. if a name matches an
> existing user, bring up the form and ask if they intend to create a new
> user, or wish to use the existing one).
>
> There are lots of options. If you do decide to do a multi-page form,
> with database submit right at the last step, there is an example of how
> I've done this in the code for pear.php.net's election creation
> interface, at
>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> .
>
>
> This code makes use of simple php-based templates found in:
>
>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
>
> Hope this helps,
> Greg
> --
> Experience the revolution, buy the PEAR Installer Manifesto
> http://www.packtpub.com/book/PEAR-installer
>
>

Dan Shirah wrote:
> I had thought about having the multiple submissions on a single form, but
> with the amount of user information that is collected and the variable
> amount of users that may need to be entered this method would not be ideal.
> (A single form that you have to scroll down a far way and the potential to
> not have enough user inputs is what prevents this method from being used)
>
> Each account is unique. It is possible that the same user could be on
> multiple accounts, therefore the account will be tied to the user each
> time.
>
> No account_id will be duplicated, but the user table can hold the same user
> multiple times tied to different accounts.
Why duplicate data? Why not do it as suggested? What do you mean by
"not ideal" ??

>
>
> On 3/20/07, Greg Beaver <EMAIL REMOVED> wrote:
>>
>> Dan Shirah wrote:
>> > In my database I have two tables. One table stores all of the account
>> > information, the other table stores all of the user information.
>> >
>> > Table 1
>> > account_id - is the primary key and is unique to each account
>> >
>> > Table 2
>> > user_id - is the primary key and is unique to each user
>> > account_id - will be set to whatever the account id is in Table 1
>> >
>> > You are suggesting that when they click "Enter another user for this
>> > account" that I save the account/user information to the database and
>> > then when the form refreshes have something like:
>> >
>> > if (!isset($_POST['submit']))
>> >
>> > to determine if this is a continuance of a multiple user submission?
>> >
>> > And then I should select the account_id that was just created? Using
>> > something like:
>> >
>> > SELECT scope_identity() FROM accounts
>> >
>> > Or is there a better way to determine the recently created
>> account_id so
>> > I can use it for any other user data that is created for this account?
>>
>> Hi Dan,
>>
>> Yes, there is a better way. What you have described is probably more
>> complex than you need, and requires more clicking by the user than is
>> necessary.
>>
>> First of all, do you allow multiple accounts for the same user? If so,
>> you're going to run into troubles with querying later on with the
>> current data schema. Generally, when I'm working with inter-linking
>> data like you describe, I construct it as:
>>
>> Table 1 account_info:
>> account information
>> account_id
>>
>> Table 2 user_info:
>> user information
>> user_id
>>
>> Table 3 account_link:
>> user_id
>> account_id
>>
>> This way, you never duplicate user information, and it is very easy to
>> link or unlink users from accounts.
>>
>> In the web form, if you allow adding up to 3 users maximum, why not just
>> put all of the input on a single page?
>>
>>

HTML Code:

>> Account information:
>>
>> Form Field 1: ________
>> ...
>>
>> User #1 (required)
>>
>> Name: _____
>> ...
>>
>> User #2 (optional)
>>
>> Name: _____
>> ...
>>
>> User #3 (optional)
>>
>> Name: _____
>> ...
>>

>>
>> In addition, you might consider either using an AJAX-based dropdown, or
>> populating a static dropdown with previous users (***uming the list of
>> users is short), so that if a previous user is entered into the account,
>> that name can be used.
>>
>> In addition, if you have all 3 users on one page, you can validate them
>> all at once, check for accidental duplicates (i.e. if a name matches an
>> existing user, bring up the form and ask if they intend to create a new
>> user, or wish to use the existing one).
>>
>> There are lots of options. If you do decide to do a multi-page form,
>> with database submit right at the last step, there is an example of how
>> I've done this in the code for pear.php.net's election creation
>> interface, at
>>
>> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
>>
>> .
>>
>>
>> This code makes use of simple php-based templates found in:
>>
>>
>> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
>>
>>
>> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
>>
>>
>> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
>>
>>
>> Hope this helps,
>> Greg
>> --
>> Experience the revolution, buy the PEAR Installer Manifesto
>> http://www.packtpub.com/book/PEAR-installer
>>
>>
>


--
Enjoy,

Jim Lucas

Different eyes see different things. Different hearts beat on different
strings. But there are times for you and me when all such things agree.

- Rush

Because in my application it is VERY VERY VERY important that I track the
specific details for any given user in any given account. The user data
changes frequently and I need to be able to track user information changes,
numbers of accounts they are ***igned to etc.

So rather than updating the user information or keeping one user and tying
them to multiple accounts it is easier to maintain a specific user per
account for our strict tracking needs.

This way I can view all accounts the user is ***ociated with, track user
information changes over months/years and provide detailed statsical reports
to auditors.


On 3/20/07, Jim Lucas <EMAIL REMOVED> wrote:
>
> Dan Shirah wrote:
> > I had thought about having the multiple submissions on a single form,
> but
> > with the amount of user information that is collected and the variable
> > amount of users that may need to be entered this method would not be
> ideal.
> > (A single form that you have to scroll down a far way and the potential
> to
> > not have enough user inputs is what prevents this method from being
> used)
> >
> > Each account is unique. It is possible that the same user could be on
> > multiple accounts, therefore the account will be tied to the user each
> > time.
> >
> > No account_id will be duplicated, but the user table can hold the same
> user
> > multiple times tied to different accounts.
> Why duplicate data? Why not do it as suggested? What do you mean by
> "not ideal" ??
>
> >
> >
> > On 3/20/07, Greg Beaver <EMAIL REMOVED> wrote:
> >>
> >> Dan Shirah wrote:
> >> > In my database I have two tables. One table stores all of the
> account
> >> > information, the other table stores all of the user information.
> >> >
> >> > Table 1
> >> > account_id - is the primary key and is unique to each account
> >> >
> >> > Table 2
> >> > user_id - is the primary key and is unique to each user
> >> > account_id - will be set to whatever the account id is in Table 1
> >> >
> >> > You are suggesting that when they click "Enter another user for this
> >> > account" that I save the account/user information to the database and
> >> > then when the form refreshes have something like:
> >> >
> >> > if (!isset($_POST['submit']))
> >> >
> >> > to determine if this is a continuance of a multiple user submission?
> >> >
> >> > And then I should select the account_id that was just created? Using
> >> > something like:
> >> >
> >> > SELECT scope_identity() FROM accounts
> >> >
> >> > Or is there a better way to determine the recently created
> >> account_id so
> >> > I can use it for any other user data that is created for this
> account?
> >>
> >> Hi Dan,
> >>
> >> Yes, there is a better way. What you have described is probably more
> >> complex than you need, and requires more clicking by the user than is
> >> necessary.
> >>
> >> First of all, do you allow multiple accounts for the same user? If so,
> >> you're going to run into troubles with querying later on with the
> >> current data schema. Generally, when I'm working with inter-linking
> >> data like you describe, I construct it as:
> >>
> >> Table 1 account_info:
> >> account information
> >> account_id
> >>
> >> Table 2 user_info:
> >> user information
> >> user_id
> >>
> >> Table 3 account_link:
> >> user_id
> >> account_id
> >>
> >> This way, you never duplicate user information, and it is very easy to
> >> link or unlink users from accounts.
> >>
> >> In the web form, if you allow adding up to 3 users maximum, why not
> just
> >> put all of the input on a single page?
> >>
> >>

HTML Code:

> >> Account information:
> >>
> >> Form Field 1: ________
> >> ...
> >>
> >> User #1 (required)
> >>
> >> Name: _____
> >> ...
> >>
> >> User #2 (optional)
> >>
> >> Name: _____
> >> ...
> >>
> >> User #3 (optional)
> >>
> >> Name: _____
> >> ...
> >>

> >>
> >> In addition, you might consider either using an AJAX-based dropdown, or
> >> populating a static dropdown with previous users (***uming the list of
> >> users is short), so that if a previous user is entered into the
> account,
> >> that name can be used.
> >>
> >> In addition, if you have all 3 users on one page, you can validate them
> >> all at once, check for accidental duplicates (i.e. if a name matches an
> >> existing user, bring up the form and ask if they intend to create a new
> >> user, or wish to use the existing one).
> >>
> >> There are lots of options. If you do decide to do a multi-page form,
> >> with database submit right at the last step, there is an example of how
> >> I've done this in the code for pear.php.net's election creation
> >> interface, at
> >>
> >>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> >>
> >> .
> >>
> >>
> >> This code makes use of simple php-based templates found in:
> >>
> >>
> >>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> >>
> >>
> >>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> >>
> >>
> >>
> http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> >>
> >>
> >> Hope this helps,
> >> Greg
> >> --
> >> Experience the revolution, buy the PEAR Installer Manifesto
> >> http://www.packtpub.com/book/PEAR-installer
> >>
> >>
> >
>
>
> --
> Enjoy,
>
> Jim Lucas
>
> Different eyes see different things. Different hearts beat on different
> strings. But there are times for you and me when all such things agree.
>
> - Rush
>
>
>
>

2007. 03. 20, kedd keltezéssel 16.31-kor Dan Shirah ezt ÃÂ*rta:
> Because in my application it is VERY VERY VERY important that I track the
> specific details for any given user in any given account. The user data
> changes frequently and I need to be able to track user information changes,
> numbers of accounts they are ***igned to etc.
>
> So rather than updating the user information or keeping one user and tying
> them to multiple accounts it is easier to maintain a specific user per
> account for our strict tracking needs.
>
> This way I can view all accounts the user is ***ociated with, track user
> information changes over months/years and provide detailed statsical reports
> to auditors.
>

I'm sure you could do all that stuff with one copy of the user data and
user-account links stored separately...

greets
Zoltán Németh


>
> On 3/20/07, Jim Lucas <EMAIL REMOVED> wrote:
> >
> > Dan Shirah wrote:
> > > I had thought about having the multiple submissions on a single form,
> > but
> > > with the amount of user information that is collected and the variable
> > > amount of users that may need to be entered this method would not be
> > ideal.
> > > (A single form that you have to scroll down a far way and the potential
> > to
> > > not have enough user inputs is what prevents this method from being
> > used)
> > >
> > > Each account is unique. It is possible that the same user could be on
> > > multiple accounts, therefore the account will be tied to the user each
> > > time.
> > >
> > > No account_id will be duplicated, but the user table can hold the same
> > user
> > > multiple times tied to different accounts.
> > Why duplicate data? Why not do it as suggested? What do you mean by
> > "not ideal" ??
> >
> > >
> > >
> > > On 3/20/07, Greg Beaver <EMAIL REMOVED> wrote:
> > >>
> > >> Dan Shirah wrote:
> > >> > In my database I have two tables. One table stores all of the
> > account
> > >> > information, the other table stores all of the user information.
> > >> >
> > >> > Table 1
> > >> > account_id - is the primary key and is unique to each account
> > >> >
> > >> > Table 2
> > >> > user_id - is the primary key and is unique to each user
> > >> > account_id - will be set to whatever the account id is in Table 1
> > >> >
> > >> > You are suggesting that when they click "Enter another user for this
> > >> > account" that I save the account/user information to the database and
> > >> > then when the form refreshes have something like:
> > >> >
> > >> > if (!isset($_POST['submit']))
> > >> >
> > >> > to determine if this is a continuance of a multiple user submission?
> > >> >
> > >> > And then I should select the account_id that was just created? Using
> > >> > something like:
> > >> >
> > >> > SELECT scope_identity() FROM accounts
> > >> >
> > >> > Or is there a better way to determine the recently created
> > >> account_id so
> > >> > I can use it for any other user data that is created for this
> > account?
> > >>
> > >> Hi Dan,
> > >>
> > >> Yes, there is a better way. What you have described is probably more
> > >> complex than you need, and requires more clicking by the user than is
> > >> necessary.
> > >>
> > >> First of all, do you allow multiple accounts for the same user? If so,
> > >> you're going to run into troubles with querying later on with the
> > >> current data schema. Generally, when I'm working with inter-linking
> > >> data like you describe, I construct it as:
> > >>
> > >> Table 1 account_info:
> > >> account information
> > >> account_id
> > >>
> > >> Table 2 user_info:
> > >> user information
> > >> user_id
> > >>
> > >> Table 3 account_link:
> > >> user_id
> > >> account_id
> > >>
> > >> This way, you never duplicate user information, and it is very easy to
> > >> link or unlink users from accounts.
> > >>
> > >> In the web form, if you allow adding up to 3 users maximum, why not
> > just
> > >> put all of the input on a single page?
> > >>
> > >>

HTML Code:

> > >> Account information:
> > >>
> > >> Form Field 1: ________
> > >> ...
> > >>
> > >> User #1 (required)
> > >>
> > >> Name: _____
> > >> ...
> > >>
> > >> User #2 (optional)
> > >>
> > >> Name: _____
> > >> ...
> > >>
> > >> User #3 (optional)
> > >>
> > >> Name: _____
> > >> ...
> > >>

> > >>
> > >> In addition, you might consider either using an AJAX-based dropdown, or
> > >> populating a static dropdown with previous users (***uming the list of
> > >> users is short), so that if a previous user is entered into the
> > account,
> > >> that name can be used.
> > >>
> > >> In addition, if you have all 3 users on one page, you can validate them
> > >> all at once, check for accidental duplicates (i.e. if a name matches an
> > >> existing user, bring up the form and ask if they intend to create a new
> > >> user, or wish to use the existing one).
> > >>
> > >> There are lots of options. If you do decide to do a multi-page form,
> > >> with database submit right at the last step, there is an example of how
> > >> I've done this in the code for pear.php.net's election creation
> > >> interface, at
> > >>
> > >>
> > http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> > >>
> > >> .
> > >>
> > >>
> > >> This code makes use of simple php-based templates found in:
> > >>
> > >>
> > >>
> > http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> > >>
> > >>
> > >>
> > http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> > >>
> > >>
> > >>
> > http://cvs.php.net/viewvc.cgi/pearwe...hp?view=markup
> > >>
> > >>
> > >> Hope this helps,
> > >> Greg
> > >> --
> > >> Experience the revolution, buy the PEAR Installer Manifesto
> > >> http://www.packtpub.com/book/PEAR-installer
> > >>
> > >>
> > >
> >
> >
> > --
> > Enjoy,
> >
> > Jim Lucas
> >
> > Different eyes see different things. Different hearts beat on different
> > strings. But there are times for you and me when all such things agree.
> >
> > - Rush
> >
> >
> >
> >

On Tue, March 20, 2007 12:46 pm, Dan Shirah wrote:
> Looking for some direction here.
>
> I have a form that collects user data. When an employee opens the
> form
> they enter in all of the user data for an account, however the account
> can
> have multiple users so the employee has the option to "Enter another
> user
> for this account" and they can do this for as many users as the
> account
> holds.
>
> What I can't figure out is how to store the first set of user details,
> have
> the blank form come up again, store the second set of user details,
> have the
> blank for come up again, insert a third set of details and then have
> all
> three sets submit to the database at the same time.
>
> Did the make sense?
>
> Would using a session work to store all this user data for a single
> submission?

You could cram as much of that as you want into $_SESSION.

Or, after the first user, create the account, and record the fact that
any subsequent users are to be tied to that account_id, and simply
keep track of the account_id from then on, for as many users as they
want to add.

It would probably be MUCH easier and cleaner to just track the
account_id and re-use it than to try to do the inserts in one big mess
at the end.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?