question on how to structure a 'cart' system in access

[overlords]

I was wondering if someone would have some pointers on how to design a cart/checkout system from inside access.



I've got a decent enough structure set up for holding a comic book inventory (that's what I do, I manage a comic shop). So far, I'm liking the continuous form design I've come up with to peruse the inventory with filters and such. My problem has to do with how to go about setting up a way to add items to a cart, structure wise.

I was wondering if a 'temporary' table is looked down upon in the access community. My idea would have been to create a table that would be a sort of 'limbo' for items that a customer is in the process of buying. You add all the items (itemID, customerID, price) to this temporary table and then when the transaction is complete, you append the entire contents of the temp table into a permanent one that holds all purchased item information and you clear the temp table. The reason I'm considering the 'temp table' is because often clients will pull out comics at the last second. Would suck to have to remove items one by one from a table that holds thousands of records, or there are cases when a client just puts everything back on the shelf at the last minute.

I'm still pretty new to access, so if I'm completely in the woods here, let me know. Any tips or suggestions are very much welcome.

Thanks.

[June7]

Here's a recent thread where user is also implementing a 'shopping cart' utility in their db. https://www.accessforums.net/forms/s...orm-33800.html

They are using temp table approach.

I use several temp tables to accomplish complex data manipulation. However, I doubt temp table is really necessary for this situation but do what works for you.

If you have a split db be sure to put temp tables in the frontend.

[rpeare]

To add to what June said, you really do not need a temporary table, there's nothing to prevent you from modifying a 'shopping cart' (adding or deleting items as a person goes through your inventory) and just have a flag on the main order that confirms the purchase, if that flag isn't set you can delete it, save it for the next time they come in etc and never have to deal with copying records from one table to another. Setting up temp tables should really be a last resort.

[overlords]

It's at the very least comforting that it's not some idea completely out of left field

Thanks for the tips, guys. This is going to be a heavy DB so I wouldn't want to build it on any 'last resort' techniques.

Going to try out what you're suggesting, rpeare. Do either of you know of an app that already has a completely checkout/cart/POS system working in it for me to tinker around with?

Thanks again.

[June7]

Google: Access database point of sale

Here is one hit http://download.cnet.com/POS-4-Busin...ml?tag=mncol;4

[overlords]

That seems more like a standalone application than something I can open up in access to learn from. Thanks anyway, I'll just keep googling.

[June7]

Depends on your goal. Do you want to spend time as a developer or as a user? There appears to be lots of POS OTS software out there and might be a lot cheaper than your time invested to develop from scratch. Here is another hit that discusses various options http://www.pcreview.co.uk/forums/poi...-t3983256.html

Take a look at the link for AdvancedPOS. Looks inexpensive. Even if you can't modify the app just working with it can give you ideas for 'look' and 'feel' of what you develop.

[overlords]

The kind of comic shop I manage handles too many different types of items and needs too many custom features not provided by any POS systems I've come across. My boss also requires a feature that allows him to export large amounts of records to excel/csv for 'comic hunting' at other shops, conventions etc. So, I'm resigned to developing it myself. Building it in stages, though. I've mostly got the inventory tracking stuff done, which isn't so hard. Some forms for data entry and what not. And I put together a pretty sweet looking continous form that will be used to browse the inventory with the help of several filters (if you remember, you helped me with this in another thread ). I've already got a seperate customer database that I created that another employee uses and she likes it a lot, says that it saves her several hours of work each week for ordering new comics for clients. Once the inventory/POS DB is up and running fine, I plan on getting the two to talk to eachother or merging them completely to have a pretty nifty software that can do everything we need it to. Right now, being able to push item ID's from my product browser form to a transaction form is my current challenge.

I'm no pro just yet, but I'm having a lot of fun learning. Do my best to not ask too many questions here so as to not wear out my welcome too soon

As always, thanks for your time.

[June7]

Sounds like you have a strong grasp of concepts and well on the way to a nice product. Don't hesitate to ask questions when you encounter issue. Good luck.