Thread: How to create a *pass-through-query* in postgresql

No, you could not do that _easily_.

You'd have to write some sort of a Postgres (C) wrapper against
unix-to-odbc libraries, to be able to do something like that. Very
nontrivial task. Also you may consider trying to use plperl and perl's
DBD interface to a DBD-to-ODBC proxy running on windows. At either case,
with current state of plperl it'll be a challenging thing...

-alex

On Wed, 6 Jun 2001, [iso-8859-1] DI Hasen�hrl wrote:

> Hello all,
> 
> I use postgresql as backend and MsAccess97 as frontend via ODBC.
> I know, how to use VBA and pass through queries to update or insert rows in postgresql-tables.
> But I don't know, how to do this the other way round, from postgresql to MsAccess.
> I want to develop a trigger, which updates or inserts rows in some local tables in MsAccess on the client side.
>  
> How can I realize a *pass through query* in postgresql ( with plpgsql ?) to be executed in MsAccess?
> 
> Is there a possibility, to send updates or inserts from postgresql-tables to local MsAccess-tables (without linked
tables)
> 
> I have the following situation:
>   1 postgresql database and some clients on different locations, connected via internet
>   I want to hold some information realy local (no linked table) to the clients and to the host, because the
connectionis not very fast
 
>   when client_1 changes a special table in the postgresql DB, this should be transmitted to a local MsAccess-table to
client_2
 
> Can I solve this problem with plpgsql????????????
> 
> Please, can anyone help me to solve this problem.
> 
> Thanks in advance
> Irina
>  
> E-Mail: i.hasenoehrl@aon.at
> 

Please don't post html mail to mailing lists - it screws up quoting.


From: "DI Hasenöhrl" <i.hasenoehrl@aon.at>

Hello all,

>I use postgresql as backend and MsAccess97 as frontend via ODBC.
>I know, how to use VBA and pass through queries to update or insert rows in
postgresql->tables.
>But I don't know, how to do this the other way round, from postgresql to
MsAccess.
>I want to develop a trigger, which updates or inserts rows in some local
tables in >MsAccess on the client side.

Don't think you can do this via ODBC. You can listen for NOTIFY signals with
a real PostgreSQL client, but I wouldn't think ODBC would support this. I
can only think of two ways to approach this:

Have a "change" table and update a timestamp in it whenever a target table
is updated. Then clients can poll once a minute or whatever and see if their
local timestamp is older than the one in the change table.

Or - rig some out-of-band communication. Have a perl script listen for
NOTIFY on the server and signal that to the clients (or just synchronise the
client tables via ODBC).

- Richard Huxton

D.I.,

> >I use postgresql as backend and MsAccess97 as frontend via ODBC.
> >I know, how to use VBA and pass through queries to update or insert
> rows in
> postgresql->tables.
> >But I don't know, how to do this the other way round, from
> postgresql to
> MsAccess.
> >I want to develop a trigger, which updates or inserts rows in some
> local
> tables in >MsAccess on the client side.

To be blunt, on top of Richard's objections, this sounds like really bad
database application design to me.  What is it you're trying to
accomplish? Chances are, it would be a much better idea to simply
relocate those "local tables" to the server.

-Josh

______AGLIO DATABASE SOLUTIONS___________________________                                      Josh Berkus Complete
informationtechnology      josh@agliodbs.com  and data management solutions       (415) 565-7293 for law firms, small
businesses       fax 621-2533   and non-profit organizations.      San Francisco
 

Josh Berkus wrote:
> 
> D.I.,
> 
> > >I want to develop a trigger, which updates or inserts rows in some
> > local
> > tables in >MsAccess on the client side.
> 
> To be blunt, on top of Richard's objections, this sounds like really bad
> database application design to me.  What is it you're trying to
> accomplish? Chances are, it would be a much better idea to simply
> relocate those "local tables" to the server.

Bad application design can equal good workaround for inadequate
resources. I've done the same sort of thing myself, but never tried to
manage "live" updates.

What this looks like is an attempt to replicate one or more tables. The
problem is, that's not going to be easy with ODBC as your connection.

- Richard Huxton