Is this Concept Possible?

[dar100111]

I wanted to get some experienced opinions on this to see if it was even possible before trying to attempt.

I was thinking of making a personalized POS system a minor league baseball team to help with their concessions and inventory and employee information with a time clock built in to manage payroll as well.  I built some basic SQLite reports work for the simple DB that I set up.  I could also build in small reporting features and use the excel functions to export my arrays into excel to make a couple of simple reports for them, or just even simple csv files.

Would autoit be able to operate on a windows tablet (guessing no)?  I could also buy some cheap cubes that just hook into a monitor if that's not possible.

If so would I be able to keep a SQLite database on a computer in their office and have the tablets connect if I made a POS system?

I might be dreaming a little to big for the capabilities.  I'm just wondering how far I can push the SQLite platform as well.  It seems very lightweight so far and they aren't going to demand a huge volume of transactions so it seemed doable.

Any advice on if this is possible or another solution without recommending buying an expensive POS system.

Thanks in advance!

[jchd]

 

If so would I be able to keep a SQLite database on a computer in their office and have the tablets connect if I made a POS system?

I might be dreaming a little to big for the capabilities.  I'm just wondering how far I can push the SQLite platform as well.  It seems very lightweight so far and they aren't going to demand a huge volume of transactions so it seemed doable.

I don't recommend using SQLite DB over any kind of network, at least not directly. There are two main reasons for that: SQLite heavily relies on file locking in concurrent access context but non of the available protocols for file locking are reliable enough to garantee normal operations. Then it's also a big big big security risk.

Better develop a web application based on whatever DB engine of your choice. Most ISPs offer MySQL but you can often insist and have SQLite or PostGres as well.

[orbs]

Any advice on if this is possible or another solution without recommending buying an expensive POS system.

 

there are many free & open source POS systems, each with its own focus and features. i wouldn't go and re-invent the wheel - although it's sometimes easier then comparing existing products 

take a look here:

http://sourceforge.net/directory/business-enterprise/financial/pointofsale/os:windows/freshness:recently-updated/

or just google "open source pos system"

[dar100111]

Thanks for the link orbs and the SQLite feedback jchd.  I am going to go check out some options on the free systems.  I may just stick to using SQLite for their inventory descriptions and employee info since just one person will be doing all the updating for that.  I don't see an issue with file locking if only one user is controlling all that.  I did wonder though about having multiple users and had read if something was being updated at just the right time that it could corrupt the SQLite DB.

[DicatoroftheUSA]

I would never design a POS system myself. Even if I was a pro POS designer.

1) If there is theft, of any kind, you don't want to be involved.

2) If the g-man comes to audit, you don't want to be raped by the government. It has the Washington monument as a phallus after all.

3) How much revenue will be lost if it goes down for X minutes at the busiest moment? Are you confident you could fix ANY bug in X minutes?

[jchd]

dar100111,

One of the specification of any decent DB engine is that it its operation is ACID compliant. See ACID properties. SQLite is fully ACID compliant and, for instance, WAL journalling mode allows one writer and multiple readers simultaneously.

Since SQLite is a small library linked or invoked alongside your application, it can't compare to a client-server architecture. In all cases, realize that even read-only queries need to lock the DB.

Again, due to security concerns, I strongly advise against direct use over the WAN.