Remote queries - Mailing list pgsql-general

From Chuck Shunk
Subject Remote queries
Date
Msg-id 001001c104ab$795c5ee0$2d0a0a0a@adelphia
Whole thread Raw
In response to RE: FOREIGN KEY  ("Trewern, Ben" <Ben.Trewern@mowlem.com>)
List pgsql-general
Hello everybody,
 
This is my first time posting to this list, so forgive me if my question seems dumb or ill informed.
 
I'm writing an application in c++ which involves a central server which is connected to by an small number (say up to 50) of clients.  The clients collect data (actually sales data--they are POS terminals) and batch it periodically to the central server.  They also periodically download info off of the central server.  Since this will be over a private network (not internet), I felt that straight SQL queries over TCP/IP would be fine.  Now, what I would LIKE to do would be something like this (if you understand my pseudo-code):
 
    INSERT INTO remote_sales_table VALUES
        (SELECT sales_info, local_terminal_id FROM local_sales_table WHERE uploaded = 'n')
 
However, as the two tables reside in two separate databases, that won't work, will it?  So, my question is, what is the best way to synchronize a master database with multiple client databases?  Right now, I have a c++ routine that does the local select to get all the sales data and then steps through each row and builds an insert for the master server.  Is there a more elegant solution?
 
If there is not a better solution already existant, I am going to build some generic procedures and objects in c++ for synchronizing tables of this sort.  Is anyone else interested in a project like this?  I'll have a project up on sourceforge in a bit.
 
By the way, this POS terminal project I'm talking about is already up on sourceforge (it's called poskiosk), but please only look at the code if you're really interested--I would be terribly embarrassed!  (It's kind of pathetic at this stage)
 
Thanks a lot!
 
Chuck Shunk

pgsql-general by date:

Previous
From: Scott Holmes
Date:
Subject: Re: Re: lo wrappers - still working on it
Next
From: Tom Lane
Date:
Subject: Re: NOT IN issue