Connecting to a postgresql Database on the Local machine

ted creedon tcreedon at easystreet.com
Sun Mar 27 21:12:30 EST 2005


 

-----Original Message-----
From: gnucash-user-bounces at gnucash.org
[mailto:gnucash-user-bounces at gnucash.org] On Behalf Of Neil Williams
Sent: Sunday, March 27, 2005 11:27 AM
To: gnucash-user at gnucash.org
Subject: Re: Connecting to a postgresql Database on the Local machine

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. 
<<<good input, investigating QOF/QSF. It sure isn't in the Msoft Lexicon.>>>
> The system is designed and runs on windows CE on up to whatever has a 
> browser.

GNU/Linux? 
<<<Konqueror, IE, etc, will actually run on a cell phone >>>
Palm OS5?
<<<Journada, WAP cell phone(90 different mfgrs models supported by MS>>>

> 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 know how to implement outside of MS. The rewrite would be pretty
straightforward. Qt has some commercial licensing issues>>>

> 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.

<<<I meant direction in the terms of SQL support only>>>

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.

<<<Amen>>>

> 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.

<<<That is the only issue I have. It isn't clear that postgres is in the
grand plan. I just don't want it disconnected, that's all>>>

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

<<<I didn't dismiss XML at all. In fact I stated that it works very well
(Gnucash->Excel) >>>

> 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.

<<<Pretty much the same conclusion. Use XML transaction log or equiv. to be
UpdateGrams to a host. 

I've reverse engineered the LinkSys WRTG54S firewall/router circuit board
electronics and run the Linux (MIPS/Infineon Processor) build tree for it.
Just for grins. Amazing what a $20 manufacturing cost 64Meg 200MHz embedded
Linux box will do. Retail is $89. (No it doesn't have a keyboard and LCD.
Not needed for a prototype.>>>

<<<As I said, Gnucash has some interesting details>>>

-- 

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




More information about the gnucash-user mailing list