From: Phil D. <ph...@du...> - 2004-02-23 23:23:54
|
> Yes PSQL does support this format, however another problem might present > itself. Postgres convert all tablename and fieldnames to lowercase. This > might present a problem, the correct method is to encase fieldnames in > quotes, which allows for uppercase letters. Alternatively, we could > simply keep all fieldnames and tablenames lowercase accross all > databases. ?? ( I.e use the database default and let it decide whether > it uses uppercase, lowercase or both.) I think mysql does this too internally. Certainly using the mysql command line client all fieldnames and table names are lower case. > Another alternative would probably be something like what you do with > the stylesheed/profile. I.e specify a set of functions that perform > specific duties, like insert client, insert transaction, etc. These > would then be scripted into one or more PHP files and will be included > based on the database type. Therefore function names stay the same. This > also allows for more advanced functionality on databases that supports > it. This is effectively what we have with the script includes/ConnectDB.inc - this script contains all DB specific functions. It is simply (?) a matter of making a new ConnectDB.inc for Postgres, MS SQL Server, Oracle, DB2, Firebird etc. > --Snip-- > > Python sure sounds great. I think integration to an existing POS system > > going to be the best thing - ideally Python or Perl? I would not be keen to > > adopt a linux only solution though - much as I love this platform. Whatever > > we think of the platform, windows represents the biggest bulk of users and > > to put a lot of work into a linux only solution .... not sure about that > > personally. > --Snip-- > Perl as language does not really lend itself to scalability, > however the great thing about Python is that it is capable of > doing what we require. And I have seen this type of cross > platform work done by another company in SA, and it works in > our energy supply consortium's offices. If Perl is the client program there is only ever one user of a POS terminal.... its just there are Perl POS systems about - rather than complete re-invention of the wheel? > --Snip-- > > This sounds like quite a knotty one!! > --Snip-- > Re : Sync > > Could it be that we could solve this problem with an EDI > like initiative ? The EDI system could send orders and invoices true. We could manage something much simpler for internal transfers of orders though. To keep location stock and all aspects of the business updated is much more serious though. Would need a very clear spec on which aspects of the business transactions are to be reflected on each system. |