On 30 Apr 2001, at 11:12, Gary Stainburn wrote:

I see this as one more reason for using PostgreSQL. snip...snip... Delphi apps work brillient with it. I use the built in Delphi database movetable to port data to/from PostgreSQL with ease.

Gary, Some questions if thats ok.... How were you connecting Delphi to PostgreSQL ? Using ODBC? Can you connect TStoredProc components to PostgreSQL procedures and invoke them from the client? Do you know of any components that can connect to PostgreSQL without having to distribute the BDE? I still use D3 c/s. I have seen references to Zeos Database Objects but cannot actually find any live sites for them. regards Richard richard@tortoise.demon.co.uk

hi

interesting thread developing here, i've a meeting tommorrow to discuss an 'open source' SIMS alternative, including discussions on reverse engineering some of it. An early estimate from the developer is that about £50,000 of

Which bits of it...

their time could provide a working basis for a project. Like many small companies, they'd need the money up front, too risky to create a product in the hope of uptake.

Some facts:- - Capita state that SIMS has 90% of the schools market for admin software, and who says Micro$oft were anti-comptetive

IIRC MS have recently put quite a bit of money into Capita. Probably explains the reason why they want to move things to Microsoft SQL. (Interestingly I now have a Windows 2000 server which can't be seen by Windows 95 on the network, but smbclient can see fine...)

- DfEE policy is forcing everyone to move to EDI for school admin

Dosn't help with a) LEA people ignoring their own policy on document formats (and emailing MS word documents with added virus.) b) propirtary EDI systems which can only run on single machines. c) EDI systems which are too complex for staff such as exams officers to understand...

- the other competitors in the market (state schools at least) include Successmaker, about 3% of the market. - none run on Linux, all locked in to Access/SQL server, although you can view them as native DB's

Or more to the point locked to Windows...

plenty of other people in the education market (Viglen, RM (?) and others) would like an alternative. Perhaps one of them can back the development.

Not to sure about RM, given my recent experience, through SWGfL... -- Mark Evans St. Peter's CofE High School Phone: +44 1392 204764 X109 Fax: +44 1392 204763

On Sat, 5 May 2001 richard@tortoise.demon.co.uk wrote:

...

I'll second the choice of PostgreSQL for the database engine, I have come to depend heavily on stored procedures which as I understand it are supported by neither PostgreSQL or MySQL. There are things that such an application would have to do that would seem to me beyond the reach of a database without some programming capability. I could give examples if it would help. This is why I was considering Interbase. Also, as Interbase is available for both Linux and Windows, a project based on it may gain more momentum. Perhaps someone knowledgeable on PostgreSQL or MySQL could comment.

PostgreSQL does have the functionality you are looking for. Try looking up triggers in the PostgreSQL manual. Michael

On Sat, 5 May 2001 richard@tortoise.demon.co.uk wrote:

...

PostgreSQL does have the functionality you are looking for. Try looking up triggers in the PostgreSQL manual. Are not triggers procedures that execute in response to an operation on a table? http://www.ca.postgresql.org/devel- corner/docs/postgres/triggers.html I mean procedures that can be called from a client, or from within another procedure, which would include, but is not limited to a trigger.

Yes - triggers are a mechanism for triggering calls to procedures whenever certain actions (e.g. SELECT, UPDATE, INSERT, DELETE) happen. You can use them to do things like consistency checks (trigger BEFORE an UPDATE or INSERT and flag an error if the check fails), creating audit trails (always add user names and timestamps to every record, or even create a separate transaction log if you want to), creating editable VIEWs, etc. Procedure creation and trigger creation is separate - you create the procedure first and then you can create a trigger that calls it if you want. You don't have to use triggers - they just seem to me to be the most obvious way to hook the procedures in, because you can then make almost everything invisible to the database client, giving you a 'clean' interface to the DB. Michael