Connecting to a postgresql Database on the Local machine

[Neil Williams]

On Sunday 27 March 2005 7:44 pm, ted creedon wrote:
> Apologies if I irked anyone with my e-mails.
>
> I have a web based Electrical Contractor's inventory control/workorder
> system written for IIS/SQL server with many of the attributes I mentioned
> in my correspondence. Particularly the data design. The data design is
> really important since the system needs to interface with whatever
> financial system a customer already has.

The internal data design is irrelevant to how the system interfaces with other 
applications. You use an intermediary to do that because it allows you to 
interact generically and therefore increase the number of applications that 
can be supported. 

As long as the design is expandable, generic and pluggable, it really doesn't 
matter to external applications how it is organised internally.

Look at QOF. It can provide the intermediary between your database server and 
other applications that don't use any form of database server, like GnuCash. 
Get your database app wrapped with QOF and export in XML that other 
applications can read. Don't expect GnuCash (or any other application) to 
move to your database design. Your data model suits your needs, it will *not* 
suit other needs, especially those like pilot-link that will never have any 
direct connection to any database program. 

There are other intermediaries like CORBA, XML-RPC. 

> The system is designed and runs on windows CE on up to whatever has a
> browser.

GNU/Linux?

Palm OS5?

> Along the way, I've discovered all the hidden licensing hooks Microsoft has
> built into their software. My system is just not salable due to the
> licensing and admin overhead costs my customers would incur. A nice
> prototype for internal use only.

Then you need to investigate how it can be implemented outside MS. Why are you 
expecting this to interface with GNU/Linux software? Will you be porting this 
to Qt or Gtk?

> I had thought of creating an interface between my system and Gnucash but
> the uncertainty in Gnucash's direction

?? What uncertainty ?? Just because we don't have glossy brochures or ads in 
computer magazines, does it mean we don't have a clear direction? gnucash.org 
has a nice summary of our direction.

Don't look for such a tight integration with other applications - it's far too 
easy to break things like that and the integration alone can raise a host of 
nasty exploits and bugs. IMHO, that's how Windows got to be such a problem 
for IE exploits - IE was too tightly integrated into the OS.

> That's why I proposed a design session or something along that line to
> insure that I could always get to a Gnucash relational database of some
> kind.

Use QOF/QSF and XML. Don't expect to fiddle with a GnuCash backend directly - 
you cannot expect to just slip data into a database and GnuCash to continue 
without problems. You need to provide the data and let GnuCash deal with 
merging it into the existing data sources, not force it in behind the scenes.

> Or get Gnucash XML into a relational database...

GnuCash doesn't require any database, it's not a database itself either. It 
can use a database but it is more than just that. The postgres stuff is 
*just* another backend, it's optional.

Don't dismiss the XML so easily, consider using it to contain the data that is 
exchanged between the applications.

> As a final thought, I'm not sure my web based application is the way to go.

I'm still looking at running GnuCash on a Psion handheld that will communicate 
with other applications using XML. There will be no database at all, it's all 
got to be done on the device and in XML data streams. There is no scope there 
for a web based solution. It's do-able because GnuCash doesn't require any 
database, per se. IMHO, we do need to retain that flexibility.

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20050327/25d54794/attachment.bin