Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
Author |
Topic |
BitShift
Yak Posting Veteran
98 Posts |
Posted - 2007-12-04 : 14:12:49
|
I want to enable my customers to purchase "tickets" that they can give their group who can then use when registering on my website, using the (prepaid) ticket number instead of paying. This way someone can buy a batch of these tickets and those numbers are reserved and once someone registers using that ticket number / id, then that number is no longer available. These tickets should be just like any other product, being added to a shopping cart etc, but once paid for the ticket # should be generated and should be unique to all other ticket#'s ever created.ideas ? so far, Ive got the basic shopping cart and other product catalog part working, its just this idea of tickets that Im not sure how best to deal with. Here is a table im starting withTicketID 4 int SponsorUserID 4 int id of user who purchased ticketOrderDate 11 datetime date ticket was purchasedFillDate 11 datetime date someone registered using this ticketTicketNotes 12 varchar misc notesTicketCode 12 varchar random and unique number The basic idea here is that only once a successful payment has been made, is a Ticket record created. So if someone purchases 100 tickets, then this equates to 100 records.ideas / suggestions welcome, thanks in advance |
|
AndrewMurphy
Master Smack Fu Yak Hacker
2916 Posts |
Posted - 2007-12-05 : 11:54:36
|
Can you prefill a tickets table with 'possible good tickets'....and then you work towards using something like select top 100 * from mytable where ticketidreservedbynotsoldyet order by newid (to select in random manner)and run some process to 'reserved' them for x minutes....and before accepting the final order check that the reserved timeframe hasn't expired.in the background you have a perpetual task looking for reserved tickets, which have not been bought after their reserved time frame...if 5/10 minutes or whatever you allow....and marking same available for selection back in the masterpool of ticketsalso i presume you are putting in a check digit scheme to prevent people "inventing" their own ticket numbers!!! |
 |
|
X002548
Not Just a Number
15586 Posts |
|
BitShift
Yak Posting Veteran
98 Posts |
Posted - 2007-12-07 : 14:55:12
|
The idea is that they would not be "reserved" (or even created) until a valid payment has been made. In other words, during the checkout and payment, a process is done to generate ticket id's (some sort of random #) by using a random number and checking the tickets that have already been sold in the past. Its after that point, a user (who had the ticket purchased for them) can create an account, but instead of paying can use this ticket id to complete the registration. Thats why the ticket #'s need to be fairly hard to guess, but short enough not to make things too difficult for the user to enter. |
 |
|
BitShift
Yak Posting Veteran
98 Posts |
Posted - 2007-12-07 : 15:01:13
|
quote: Originally posted by X002548 why would you block tickets from potentioal clients by "reserving" them?If they pay for them, then there off the market. Why limit your customer base?What if they all get reserved and no one pays?
See previous reply. Ticket ID's wouldnt get created until a valid payment is made. Then they are there until someone uses them during their registration process. Its after the purchase of the tickets that their ID's would be generated. When someone registers using that ticket id, its FillDate would be populated and no longer be available for others to use when registering. The idea would be for the purchasing user to give each potential user a separate ticket id or number, after completing the purchase.Hope that was clear. |
 |
|
|
|
|
|
|