Thread: Connecting remotely.

Connecting remotely.

From
"Adam Lang"
Date:
This may be a silly question, but how does *nix systems speak to a remote
database without ODBC, like Windows?

As an example, PHP... I have Apache/PHP on one server, and the database on
another.  How does it do remote calls?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company



Re: Connecting remotely.

From
Marko Kreen
Date:
On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> This may be a silly question, but how does *nix systems speak to a remote
> database without ODBC, like Windows?

Database's client side libraries take care of that.  But that
means linking your app with some particular database library.
e.g. PHP has php_pgsql, php_sybase...  if you want your
app to be database-agnostic, you can link it with e.g. UnixODBC,
which should do the database-specific work.

> As an example, PHP... I have Apache/PHP on one server, and the database on
> another.  How does it do remote calls?

$db = pg_connect("host=another.net port=5432 ... ");

-- 
marko



Re: Connecting remotely.

From
"Adam Lang"
Date:
That's what I was figuring... so... is it possible to take those files,
compile them into a dll and make a postgresql-specific remote connection
library?  So, say instead of referencing ADO in Visual Basic and using the
ODBC driver, merely wrap up necessary functionality of the client side
libraries?  Would that be hard? (Never made a DLL before, so unsure).
Granted it breaks the idea of writing code to use on any database, but if
you are making an in-house application and have control over the database...
Also, it wouldn't help Access oriented people, but this would be used for a
bit more hard core integration, something that if you want, you shouldn't be
using Access for a front end anyway.

What are people's thoughts?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Marko Kreen" <marko@l-t.ee>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 9:50 AM
Subject: Re: [INTERFACES] Connecting remotely.


> On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> > This may be a silly question, but how does *nix systems speak to a
remote
> > database without ODBC, like Windows?
>
> Database's client side libraries take care of that.  But that
> means linking your app with some particular database library.
> e.g. PHP has php_pgsql, php_sybase...  if you want your
> app to be database-agnostic, you can link it with e.g. UnixODBC,
> which should do the database-specific work.
>
> > As an example, PHP... I have Apache/PHP on one server, and the database
on
> > another.  How does it do remote calls?
>
> $db = pg_connect("host=another.net port=5432 ... ");
>
> --
> marko



RE: Connecting remotely.

From
"Clark, Joel"
Date:
Yes, you can build libpq into libpq.dll.  You can then add the function
declarations at the top, much like you would for an API call.  Alternatively
you could wrap a COM object around the DLL and use it that way.

Joel

-----Original Message-----
From: Adam Lang [mailto:aalang@rutgersinsurance.com]
Sent: Wednesday, November 01, 2000 9:53 AM
Cc: pgsql-interfaces
Subject: Re: [INTERFACES] Connecting remotely.


That's what I was figuring... so... is it possible to take those files,
compile them into a dll and make a postgresql-specific remote connection
library?  So, say instead of referencing ADO in Visual Basic and using the
ODBC driver, merely wrap up necessary functionality of the client side
libraries?  Would that be hard? (Never made a DLL before, so unsure).
Granted it breaks the idea of writing code to use on any database, but if
you are making an in-house application and have control over the database...
Also, it wouldn't help Access oriented people, but this would be used for a
bit more hard core integration, something that if you want, you shouldn't be
using Access for a front end anyway.

What are people's thoughts?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Marko Kreen" <marko@l-t.ee>
To: "Adam Lang" <aalang@rutgersinsurance.com>
Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 9:50 AM
Subject: Re: [INTERFACES] Connecting remotely.


> On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> > This may be a silly question, but how does *nix systems speak to a
remote
> > database without ODBC, like Windows?
>
> Database's client side libraries take care of that.  But that
> means linking your app with some particular database library.
> e.g. PHP has php_pgsql, php_sybase...  if you want your
> app to be database-agnostic, you can link it with e.g. UnixODBC,
> which should do the database-specific work.
>
> > As an example, PHP... I have Apache/PHP on one server, and the database
on
> > another.  How does it do remote calls?
>
> $db = pg_connect("host=another.net port=5432 ... ");
>
> --
> marko


RE: Connecting remotely.

From
Dave Page
Date:

> -----Original Message-----
> From: Adam Lang [mailto:aalang@rutgersinsurance.com]
> Sent: 01 November 2000 14:53
> Cc: pgsql-interfaces
> Subject: Re: [INTERFACES] Connecting remotely.
> 
> 
> That's what I was figuring... so... is it possible to take 
> those files,
> compile them into a dll and make a postgresql-specific remote 
> connection
> library?  So, say instead of referencing ADO in Visual Basic 
> and using the
> ODBC driver, merely wrap up necessary functionality of the client side
> libraries?  Would that be hard? (Never made a DLL before, so unsure).

Many before you have tried this and failed miserably!! :-)

Seriously though, I think you would be creating a horrendous amount of work
for yourself (having considered the idea for 18 months or so myself). IMHO
time would be far better spent writing an OLEDB provider for PostgreSQL (a
native one, not one using the Simple Provider interface). At least then you
can still manipulate data in recordset objects which aren't really that bad
to work with and are very useful when you attach them to a hidden data
control so you can bind other controls to them.

Regards,
Dave.


Re: Connecting remotely.

From
"Sergio A. Kessler"
Date:
"Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000 09:52:35 
-0500, escribió:

[...]
>
>What are people's thoughts?

people's thoughts are that you really want to design a multi-thier
design (for example a 3 layer design), where
                                           /  client1 (browser)database  <--->   bussines rules           -  client2
(browser)                (ie. apache, php,...)     \  .....
 


if your client has direct access to the database, you design is broken...

sergio



Re: Connecting remotely.

From
"Adam Lang"
Date:
Well, I was mostly feeling out ideas... mainly because I don't know how to
write com objects or an OLE DB provider. :P

The 6th through the 10th I have a training course for VB and it gets into
Active X DLLs and Com objects, so naturally I was thinking of what I would
use my new found power for and I thought of that as a possibility.

As for the ole db... does anyone have an idea where to start looking for
that info?  Would it have to be written in C?  I found a company that sells
software that creates ole dbs...

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Dave Page" <dpage@vale-housing.co.uk>
To: "'Adam Lang'" <aalang@rutgersinsurance.com>;
<pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 10:32 AM
Subject: RE: [INTERFACES] Connecting remotely.


>
>
> > -----Original Message-----
> > From: Adam Lang [mailto:aalang@rutgersinsurance.com]
> > Sent: 01 November 2000 14:53
> > Cc: pgsql-interfaces
> > Subject: Re: [INTERFACES] Connecting remotely.
> >
> >
> > That's what I was figuring... so... is it possible to take
> > those files,
> > compile them into a dll and make a postgresql-specific remote
> > connection
> > library?  So, say instead of referencing ADO in Visual Basic
> > and using the
> > ODBC driver, merely wrap up necessary functionality of the client side
> > libraries?  Would that be hard? (Never made a DLL before, so unsure).
>
> Many before you have tried this and failed miserably!! :-)
>
> Seriously though, I think you would be creating a horrendous amount of
work
> for yourself (having considered the idea for 18 months or so myself). IMHO
> time would be far better spent writing an OLEDB provider for PostgreSQL (a
> native one, not one using the Simple Provider interface). At least then
you
> can still manipulate data in recordset objects which aren't really that
bad
> to work with and are very useful when you attach them to a hidden data
> control so you can bind other controls to them.
>
> Regards,
> Dave.



Re: Connecting remotely.

From
"Adam Lang"
Date:
That's sort of what I was thinking... Make a reference to it and use it much
like regobj.dll for modifying Registry in windows...

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Clark, Joel" <jclark@lendingtree.com>
To: "'Adam Lang'" <aalang@rutgersinsurance.com>
Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 10:35 AM
Subject: RE: [INTERFACES] Connecting remotely.


> Yes, you can build libpq into libpq.dll.  You can then add the function
> declarations at the top, much like you would for an API call.
Alternatively
> you could wrap a COM object around the DLL and use it that way.
>
> Joel
>
> -----Original Message-----
> From: Adam Lang [mailto:aalang@rutgersinsurance.com]
> Sent: Wednesday, November 01, 2000 9:53 AM
> Cc: pgsql-interfaces
> Subject: Re: [INTERFACES] Connecting remotely.
>
>
> That's what I was figuring... so... is it possible to take those files,
> compile them into a dll and make a postgresql-specific remote connection
> library?  So, say instead of referencing ADO in Visual Basic and using the
> ODBC driver, merely wrap up necessary functionality of the client side
> libraries?  Would that be hard? (Never made a DLL before, so unsure).
> Granted it breaks the idea of writing code to use on any database, but if
> you are making an in-house application and have control over the
database...
> Also, it wouldn't help Access oriented people, but this would be used for
a
> bit more hard core integration, something that if you want, you shouldn't
be
> using Access for a front end anyway.
>
> What are people's thoughts?
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
> ----- Original Message -----
> From: "Marko Kreen" <marko@l-t.ee>
> To: "Adam Lang" <aalang@rutgersinsurance.com>
> Cc: "pgsql-interfaces" <pgsql-interfaces@postgresql.org>
> Sent: Wednesday, November 01, 2000 9:50 AM
> Subject: Re: [INTERFACES] Connecting remotely.
>
>
> > On Wed, Nov 01, 2000 at 09:29:47AM -0500, Adam Lang wrote:
> > > This may be a silly question, but how does *nix systems speak to a
> remote
> > > database without ODBC, like Windows?
> >
> > Database's client side libraries take care of that.  But that
> > means linking your app with some particular database library.
> > e.g. PHP has php_pgsql, php_sybase...  if you want your
> > app to be database-agnostic, you can link it with e.g. UnixODBC,
> > which should do the database-specific work.
> >
> > > As an example, PHP... I have Apache/PHP on one server, and the
database
> on
> > > another.  How does it do remote calls?
> >
> > $db = pg_connect("host=another.net port=5432 ... ");
> >
> > --
> > marko



Re: Connecting remotely.

From
"Adam Lang"
Date:
What's the difference between having the client use ADO to talk to the
database as opposed to an interface using the postgresql client libraries?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
To: <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 11:18 AM
Subject: Re: [INTERFACES] Connecting remotely.


> "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000 09:52:35
> -0500, escribió:
>
> [...]
> >
> >What are people's thoughts?
>
> people's thoughts are that you really want to design a multi-thier
> design (for example a 3 layer design), where
>
>                                             /  client1 (browser)
>  database  <--->   bussines rules           -  client2 (browser)
>                   (ie. apache, php,...)     \  .....
>
>
> if your client has direct access to the database, you design is broken...
>
> sergio



RE: Connecting remotely.

From
Magnus Hagander
Date:
> As for the ole db... does anyone have an idea where to start 
> looking for that info?  
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c
s7.htm

> Would it have to be written in C?  I found a 
> company that sells
> software that creates ole dbs...
It shuold be possible to write it in any language that can produce COM
objects which support the OLE-DB interfaces (there are lots of them). C++ is
probably the most common langauge used, but there are examples in Java and
Visual Basic as well (samples available at
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298
xb.htm).

//Magnus


RE: Connecting remotely.

From
Dave Page
Date:

> -----Original Message-----
> From: Adam Lang [mailto:aalang@rutgersinsurance.com]
> Sent: 01 November 2000 16:40
> To: pgsql-interfaces@postgresql.org
> Subject: Re: [INTERFACES] Connecting remotely.
> 
> 
> What's the difference between having the client use ADO to talk to the
> database as opposed to an interface using the postgresql 
> client libraries?
> 

Nothing, I would say. In my mind, Sergio is saying that any app written with
libpq or libpq++ or any other interface that doesn't include some kind of
middleware is broken. Surely that would include psql, pgAccess, pgAdmin,
anything using ODBC written in C or VB or C++?

Or have I missed the point completely?

Regards,
Dave.

> 
> > "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 
> 2000 09:52:35
> > -0500, escribió:
> >
> > [...]
> > >
> > >What are people's thoughts?
> >
> > people's thoughts are that you really want to design a multi-thier
> > design (for example a 3 layer design), where
> >
> >                                             /  client1 (browser)
> >  database  <--->   bussines rules           -  client2 (browser)
> >                   (ie. apache, php,...)     \  .....
> >
> >
> > if your client has direct access to the database, you 
> design is broken...
> >
> > sergio
> 


Re: Connecting remotely.

From
"Adam Lang"
Date:
So in other words I should have a client that talks to a server application,
which in turn talks to the database?

Again, this n-tier stuff is nice if the person writing the app has to do it
independent of a back end, but when you are writing for a specific
instances, all it seems to do is make things harder...

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Dave Page" <dpage@vale-housing.co.uk>
To: "'Adam Lang'" <aalang@rutgersinsurance.com>;
<pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 12:15 PM
Subject: RE: [INTERFACES] Connecting remotely.


>
>
> > -----Original Message-----
> > From: Adam Lang [mailto:aalang@rutgersinsurance.com]
> > Sent: 01 November 2000 16:40
> > To: pgsql-interfaces@postgresql.org
> > Subject: Re: [INTERFACES] Connecting remotely.
> >
> >
> > What's the difference between having the client use ADO to talk to the
> > database as opposed to an interface using the postgresql
> > client libraries?
> >
>
> Nothing, I would say. In my mind, Sergio is saying that any app written
with
> libpq or libpq++ or any other interface that doesn't include some kind of
> middleware is broken. Surely that would include psql, pgAccess, pgAdmin,
> anything using ODBC written in C or VB or C++?
>
> Or have I missed the point completely?
>
> Regards,
> Dave.
>
> >
> > > "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov
> > 2000 09:52:35
> > > -0500, escribió:
> > >
> > > [...]
> > > >
> > > >What are people's thoughts?
> > >
> > > people's thoughts are that you really want to design a multi-thier
> > > design (for example a 3 layer design), where
> > >
> > >                                             /  client1 (browser)
> > >  database  <--->   bussines rules           -  client2 (browser)
> > >                   (ie. apache, php,...)     \  .....
> > >
> > >
> > > if your client has direct access to the database, you
> > design is broken...
> > >
> > > sergio
> >



Re: Connecting remotely.

From
ken@ori-ind.com
Date:
For single tier access to pg via libpq.dll check out the following:

http://www.zeos.dn.ua/eng/zeos_zdo_main.html

Ken

At 13:24 11/01/2000 -0500, Adam Lang wrote:
>So in other words I should have a client that talks to a server application,
>which in turn talks to the database?
>
>Again, this n-tier stuff is nice if the person writing the app has to do it
>independent of a back end, but when you are writing for a specific
>instances, all it seems to do is make things harder...
>
>Adam Lang
>Systems Engineer
>Rutgers Casualty Insurance Company
>----- Original Message -----
>From: "Dave Page" <dpage@vale-housing.co.uk>
>To: "'Adam Lang'" <aalang@rutgersinsurance.com>;
><pgsql-interfaces@postgresql.org>
>Sent: Wednesday, November 01, 2000 12:15 PM
>Subject: RE: [INTERFACES] Connecting remotely.
>
>
>>
>>
>> > -----Original Message-----
>> > From: Adam Lang [mailto:aalang@rutgersinsurance.com]
>> > Sent: 01 November 2000 16:40
>> > To: pgsql-interfaces@postgresql.org
>> > Subject: Re: [INTERFACES] Connecting remotely.
>> >
>> >
>> > What's the difference between having the client use ADO to talk to the
>> > database as opposed to an interface using the postgresql
>> > client libraries?
>> >
>>
>> Nothing, I would say. In my mind, Sergio is saying that any app written
>with
>> libpq or libpq++ or any other interface that doesn't include some kind of
>> middleware is broken. Surely that would include psql, pgAccess, pgAdmin,
>> anything using ODBC written in C or VB or C++?
>>
>> Or have I missed the point completely?
>>
>> Regards,
>> Dave.
>>
>> >
>> > > "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov
>> > 2000 09:52:35
>> > > -0500, escribió:
>> > >
>> > > [...]
>> > > >
>> > > >What are people's thoughts?
>> > >
>> > > people's thoughts are that you really want to design a multi-thier
>> > > design (for example a 3 layer design), where
>> > >
>> > >                                             /  client1 (browser)
>> > >  database  <--->   bussines rules           -  client2 (browser)
>> > >                   (ie. apache, php,...)     \  .....
>> > >
>> > >
>> > > if your client has direct access to the database, you
>> > design is broken...
>> > >
>> > > sergio
>> >
>


RE: Connecting remotely.

From
"Clark, Joel"
Date:
One layer of abstraction...

If you use ADO you gain some portability across backends (limited, but still
enough to warrant its investigation).  If you code to libpq.dll, then not
only is the SQL PG specific, but the connection libraries as well.

Joel

-----Original Message-----
From: Adam Lang [mailto:aalang@rutgersinsurance.com]
Sent: Wednesday, November 01, 2000 11:40 AM
To: pgsql-interfaces@postgresql.org
Subject: Re: [INTERFACES] Connecting remotely.


What's the difference between having the client use ADO to talk to the
database as opposed to an interface using the postgresql client libraries?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
To: <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 11:18 AM
Subject: Re: [INTERFACES] Connecting remotely.


> "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000 09:52:35
> -0500, escribió:
>
> [...]
> >
> >What are people's thoughts?
>
> people's thoughts are that you really want to design a multi-thier
> design (for example a 3 layer design), where
>
>                                             /  client1 (browser)
>  database  <--->   bussines rules           -  client2 (browser)
>                   (ie. apache, php,...)     \  .....
>
>
> if your client has direct access to the database, you design is broken...
>
> sergio


Re: Connecting remotely.

From
"Adam Lang"
Date:
That I am aware of. But my point is that if I am not concerned with the
application interfacing on other than postgres, it isn't an issue, correct?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Clark, Joel" <jclark@lendingtree.com>
To: "'Adam Lang'" <aalang@rutgersinsurance.com>;
<pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 3:14 PM
Subject: RE: [INTERFACES] Connecting remotely.


> One layer of abstraction...
>
> If you use ADO you gain some portability across backends (limited, but
still
> enough to warrant its investigation).  If you code to libpq.dll, then not
> only is the SQL PG specific, but the connection libraries as well.
>
> Joel
>
> -----Original Message-----
> From: Adam Lang [mailto:aalang@rutgersinsurance.com]
> Sent: Wednesday, November 01, 2000 11:40 AM
> To: pgsql-interfaces@postgresql.org
> Subject: Re: [INTERFACES] Connecting remotely.
>
>
> What's the difference between having the client use ADO to talk to the
> database as opposed to an interface using the postgresql client libraries?
>
> Adam Lang
> Systems Engineer
> Rutgers Casualty Insurance Company
> ----- Original Message -----
> From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
> To: <aalang@rutgersinsurance.com>; <pgsql-interfaces@postgresql.org>
> Sent: Wednesday, November 01, 2000 11:18 AM
> Subject: Re: [INTERFACES] Connecting remotely.
>
>
> > "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000
09:52:35
> > -0500, escribió:
> >
> > [...]
> > >
> > >What are people's thoughts?
> >
> > people's thoughts are that you really want to design a multi-thier
> > design (for example a 3 layer design), where
> >
> >                                             /  client1 (browser)
> >  database  <--->   bussines rules           -  client2 (browser)
> >                   (ie. apache, php,...)     \  .....
> >
> >
> > if your client has direct access to the database, you design is
broken...
> >
> > sergio



RE: Connecting remotely.

From
"Clark, Joel"
Date:
I have created a project on greatbridge's site (www.greatbridge.org) to do
just that (assuming life doesn't get in the way).  I have not started yet,
so I can't really give specifics.  It will be written C++ (MS Visual C++ 6
to be exact, since that is what I have) using MS's SDK (downloadable from
MSDN).

Joel

-----Original Message-----
From: Magnus Hagander [mailto:mha@sollentuna.net]
Sent: Wednesday, November 01, 2000 12:12 PM
To: 'Adam Lang'; pgsql-interfaces
Subject: RE: [INTERFACES] Connecting remotely.


> As for the ole db... does anyone have an idea where to start 
> looking for that info?  
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c
s7.htm

> Would it have to be written in C?  I found a 
> company that sells
> software that creates ole dbs...
It shuold be possible to write it in any language that can produce COM
objects which support the OLE-DB interfaces (there are lots of them). C++ is
probably the most common langauge used, but there are examples in Java and
Visual Basic as well (samples available at
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298
xb.htm).

//Magnus


Re: Connecting remotely.

From
"Adam Lang"
Date:
So you are writing an OLE DB provider?  I'm going to have to set up an altar
to you at my house... ;)

I know it may be a stupid question, but are they overly hard?  I mean, if
you have a lot of connectivity code already existent in the ODBC and libpq,
does it make the job a lot easier?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Clark, Joel" <jclark@lendingtree.com>
To: "'Magnus Hagander'" <mha@sollentuna.net>; "'Adam Lang'"
<aalang@rutgersinsurance.com>; "pgsql-interfaces"
<pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 3:31 PM
Subject: RE: [INTERFACES] Connecting remotely.


> I have created a project on greatbridge's site (www.greatbridge.org) to do
> just that (assuming life doesn't get in the way).  I have not started yet,
> so I can't really give specifics.  It will be written C++ (MS Visual C++ 6
> to be exact, since that is what I have) using MS's SDK (downloadable from
> MSDN).
>
> Joel
>
> -----Original Message-----
> From: Magnus Hagander [mailto:mha@sollentuna.net]
> Sent: Wednesday, November 01, 2000 12:12 PM
> To: 'Adam Lang'; pgsql-interfaces
> Subject: RE: [INTERFACES] Connecting remotely.
>
>
> > As for the ole db... does anyone have an idea where to start
> > looking for that info?
>
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c
> s7.htm
>
> > Would it have to be written in C?  I found a
> > company that sells
> > software that creates ole dbs...
> It shuold be possible to write it in any language that can produce COM
> objects which support the OLE-DB interfaces (there are lots of them). C++
is
> probably the most common langauge used, but there are examples in Java and
> Visual Basic as well (samples available at
>
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298
> xb.htm).
>
> //Magnus



RE: Connecting remotely.

From
"Clark, Joel"
Date:
After consulting MSDN, I am pretty sure that I will be able to wrap the
provider around libpq.  If not, I won't be completing the provider.  *g*
The only task I have listed for my project so far is building a
strategy...included in this is a feasability check.

No need for altars, but testers/documenters might come in handy if I ever
get something up and running.  :)

Joel

-----Original Message-----
From: Adam Lang [mailto:aalang@rutgersinsurance.com]
Sent: Wednesday, November 01, 2000 3:52 PM
To: pgsql-interfaces
Subject: Re: [INTERFACES] Connecting remotely.


So you are writing an OLE DB provider?  I'm going to have to set up an altar
to you at my house... ;)

I know it may be a stupid question, but are they overly hard?  I mean, if
you have a lot of connectivity code already existent in the ODBC and libpq,
does it make the job a lot easier?

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Clark, Joel" <jclark@lendingtree.com>
To: "'Magnus Hagander'" <mha@sollentuna.net>; "'Adam Lang'"
<aalang@rutgersinsurance.com>; "pgsql-interfaces"
<pgsql-interfaces@postgresql.org>
Sent: Wednesday, November 01, 2000 3:31 PM
Subject: RE: [INTERFACES] Connecting remotely.


> I have created a project on greatbridge's site (www.greatbridge.org) to do
> just that (assuming life doesn't get in the way).  I have not started yet,
> so I can't really give specifics.  It will be written C++ (MS Visual C++ 6
> to be exact, since that is what I have) using MS's SDK (downloadable from
> MSDN).
>
> Joel
>
> -----Original Message-----
> From: Magnus Hagander [mailto:mha@sollentuna.net]
> Sent: Wednesday, November 01, 2000 12:12 PM
> To: 'Adam Lang'; pgsql-interfaces
> Subject: RE: [INTERFACES] Connecting remotely.
>
>
> > As for the ole db... does anyone have an idea where to start
> > looking for that info?
>
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/oled0c
> s7.htm
>
> > Would it have to be written in C?  I found a
> > company that sells
> > software that creates ole dbs...
> It shuold be possible to write it in any language that can produce COM
> objects which support the OLE-DB interfaces (there are lots of them). C++
is
> probably the most common langauge used, but there are examples in Java and
> Visual Basic as well (samples available at
>
http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/dasdk/osp298
> xb.htm).
>
> //Magnus


Re: Connecting remotely - multi tier

From
Cedar Cox
Date:
You seem to have given this a lot of thought so let me ask a question.  
How do I implement a user login system?  If the user knows their password
(and don't they always?..), what's to stop them from finding and
contacting the database directly, bypassing the middle tier?  I haven't
been able to find a solution to this problem.  Every time I try to think
about it by brain goes into a recursive loop!  :o

Ideas?

-Cedar


On Wed, 1 Nov 2000, Sergio A. Kessler wrote:

> "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000 09:52:35 
> -0500, escribió:
> 
> [...]
> >
> >What are people's thoughts?
> 
> people's thoughts are that you really want to design a multi-thier
> design (for example a 3 layer design), where
> 
>                                             /  client1 (browser)
>  database  <--->   bussines rules           -  client2 (browser)
>                   (ie. apache, php,...)     \  .....
> 
> 
> if your client has direct access to the database, you design is broken...
> 
> sergio
> 
> 



Re: Connecting remotely - multi tier

From
Greg Speegle
Date:
Hi all,

I'm new to this mailing list, so apologies up front if I commit a faux pas.

In general, the database will reside on a different machine from the web
server, and will not allow access from any machines other than some
internal ones.

Also, the login to the system should not be the same as the login to the
database. The middle tier has a different login to handle that.

If you want to avoid allowing the user to connect directly to the middle
tier and use it in unexpected ways, one option would be to use serialized
object communication between an applet (as the front end) and a
servlet (as the middle tier). You can then put encryption and other features
into your objects to further restrict user access.

Hope that helps!

Greg Speegle
Baylor University

Cedar Cox wrote:

> You seem to have given this a lot of thought so let me ask a question.
> How do I implement a user login system?  If the user knows their password
> (and don't they always?..), what's to stop them from finding and
> contacting the database directly, bypassing the middle tier?  I haven't
> been able to find a solution to this problem.  Every time I try to think
> about it by brain goes into a recursive loop!  :o
>
> Ideas?
>
> -Cedar
>
> On Wed, 1 Nov 2000, Sergio A. Kessler wrote:
>
> > "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000 09:52:35
> > -0500, escribió:
> >
> > [...]
> > >
> > >What are people's thoughts?
> >
> > people's thoughts are that you really want to design a multi-thier
> > design (for example a 3 layer design), where
> >
> >                                             /  client1 (browser)
> >  database  <--->   bussines rules           -  client2 (browser)
> >                   (ie. apache, php,...)     \  .....
> >
> >
> > if your client has direct access to the database, you design is broken...
> >
> > sergio
> >
> >



Re: Connecting remotely - multi tier

From
"Sergio A. Kessler"
Date:
Cedar Cox <cedarc@visionforisrael.com> el día Thu, 2 Nov 2000 17:18:48 +0200 
(IST), escribió:

>You seem to have given this a lot of thought so let me ask a question.  
>How do I implement a user login system?  If the user knows their password
>(and don't they always?..), what's to stop them from finding and
>contacting the database directly, bypassing the middle tier?

because you setup the database (ie. pg_hba.conf) so that ONLY and only
the machine thas has the middle tier can connect to the database directly,
no other machine in the world can conect to the databse bypassing the
middle tier (even if the user know all passwords).

>  I haven't
>been able to find a solution to this problem.  Every time I try to think
>about it by brain goes into a recursive loop!  :o

this is what I've done:

I implemented a login system with php (using http authentication), 
so the machine running apache and php (the only machine with direct 
access to the db) connect with with the db with the username & password 
in behalf of the user.

this is my routine:

function sak_db_auth()
{ global $db_conf; global $PHP_AUTH_USER; global $PHP_AUTH_PW;

//  header("Cache-Control: no-cache");
//  header("Pragma: no-cache"); header("Expires: Sat, Jan 01 2000 01:01:01 GMT");
 function login_prompt() {   global $db_conf;   header("WWW-Authenticate: Basic realm=\"" . $db_conf["realm"] . "\"");
header("HTTP/1.0 401 Unauthorized");   echo "<meta HTTP-EQUIV=\"Refresh\" CONTENT=\"0; URL=" . 
 
$db_conf["url_on_cancel"] . "\">";   exit; }
 if (!isset($PHP_AUTH_USER)) {   login_prompt(); } else {   if($PHP_AUTH_USER && $PHP_AUTH_PW)   {     if
(!in_array($PHP_AUTH_USER,$db_conf["allowed_users"]))     {       return(false);     }
 
     $db_conf["user"] = $PHP_AUTH_USER;     $db_conf["password"] = $PHP_AUTH_PW;     $db_conf["str_conn"] = "dbname=" .
$db_conf["dbname"]. " user=" . 
 
$db_conf["user"] . " password=" . $db_conf["password"];
     $db = @pg_connect($db_conf["str_conn"]);
     if (!$db) {       $result = false;     } else {       pg_close($db);       $result = true;     }   } }
return($result);
}

in this way the users cannot connect directly to the db with crap 
like access, excel and so on ..

>On Wed, 1 Nov 2000, Sergio A. Kessler wrote:
>
>> "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000 09:52:35 
>> -0500, escribió:
>> 
>> [...]
>> >
>> >What are people's thoughts?
>> 
>> people's thoughts are that you really want to design a multi-thier
>> design (for example a 3 layer design), where
>> 
>>                                             /  client1 (browser)
>>  database  <--->   bussines rules           -  client2 (browser)
>>                   (ie. apache, php,...)     \  .....
>> 
>> 
>> if your client has direct access to the database, you design is broken...
>> 
>> sergio
>> 
>> 



Re: Connecting remotely - multi tier

From
Bob Kline
Date:
On Thu, 2 Nov 2000, Cedar Cox wrote:

> 
> You seem to have given this a lot of thought so let me ask a
> question.  How do I implement a user login system?  If the user
> knows their password (and don't they always?..), what's to stop them
> from finding and contacting the database directly, bypassing the
> middle tier?  I haven't been able to find a solution to this
> problem.  Every time I try to think about it by brain goes into a
> recursive loop!  :o
> 
> Ideas?

The solution is decoupling your application's security from that imposed
by the DBMS.

-- 
Bob Kline
mailto:bkline@rksystems.com
http://www.rksystems.com



Re: Connecting remotely - multi tier

From
"Adam Lang"
Date:
Ok... so if I am writing a distributed application in windows that will use
a Postgresql backend, I should have the client interface another "server"
application, which will inturn access/retrieve informaton from the database?

Well, how about this... I have a VB client application that uses a NT server
VB application for the middle tier, and the postgresql database is on a
linux server.  Is it ok THEN to wrap the libpq into a dll and COM object for
the middle tier to access the database, as oppsoed to using ODBC?

In essence that is what I was asking... the possibility a Postgresql API
that I could use, as opposed to a generalised ODBC driver.  Whether for a
client or a middle tier, it doesn't matter.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
To: <cedarc@visionforisrael.com>; <pgsql-interfaces@postgresql.org>
Sent: Thursday, November 02, 2000 10:03 AM
Subject: Re: [INTERFACES] Connecting remotely - multi tier


> Cedar Cox <cedarc@visionforisrael.com> el día Thu, 2 Nov 2000 17:18:48
+0200
> (IST), escribió:
>
> >You seem to have given this a lot of thought so let me ask a question.
> >How do I implement a user login system?  If the user knows their password
> >(and don't they always?..), what's to stop them from finding and
> >contacting the database directly, bypassing the middle tier?
>
> because you setup the database (ie. pg_hba.conf) so that ONLY and only
> the machine thas has the middle tier can connect to the database directly,
> no other machine in the world can conect to the databse bypassing the
> middle tier (even if the user know all passwords).
>
> >  I haven't
> >been able to find a solution to this problem.  Every time I try to think
> >about it by brain goes into a recursive loop!  :o
>
> this is what I've done:
>
> I implemented a login system with php (using http authentication),
> so the machine running apache and php (the only machine with direct
> access to the db) connect with with the db with the username & password
> in behalf of the user.
>
> this is my routine:
>
> function sak_db_auth()
> {
>   global $db_conf;
>   global $PHP_AUTH_USER;
>   global $PHP_AUTH_PW;
>
> //  header("Cache-Control: no-cache");
> //  header("Pragma: no-cache");
>   header("Expires: Sat, Jan 01 2000 01:01:01 GMT");
>
>   function login_prompt()
>   {
>     global $db_conf;
>     header("WWW-Authenticate: Basic realm=\"" . $db_conf["realm"] . "\"");
>     header("HTTP/1.0 401 Unauthorized");
>     echo "<meta HTTP-EQUIV=\"Refresh\" CONTENT=\"0; URL=" .
> $db_conf["url_on_cancel"] . "\">";
>     exit;
>   }
>
>   if (!isset($PHP_AUTH_USER)) {
>     login_prompt();
>   } else
>   {
>     if($PHP_AUTH_USER && $PHP_AUTH_PW)
>     {
>       if (!in_array($PHP_AUTH_USER, $db_conf["allowed_users"]))
>       {
>         return(false);
>       }
>
>       $db_conf["user"] = $PHP_AUTH_USER;
>       $db_conf["password"] = $PHP_AUTH_PW;
>       $db_conf["str_conn"] = "dbname=" . $db_conf["dbname"] . " user=" .
> $db_conf["user"] . " password=" . $db_conf["password"];
>
>       $db = @pg_connect($db_conf["str_conn"]);
>
>       if (!$db) {
>         $result = false;
>       } else {
>         pg_close($db);
>         $result = true;
>       }
>     }
>   }
>   return($result);
> }
>
> in this way the users cannot connect directly to the db with crap
> like access, excel and so on ..
>
> >On Wed, 1 Nov 2000, Sergio A. Kessler wrote:
> >
> >> "Adam Lang" <aalang@rutgersinsurance.com> el día Wed, 1 Nov 2000
09:52:35
> >> -0500, escribió:
> >>
> >> [...]
> >> >
> >> >What are people's thoughts?
> >>
> >> people's thoughts are that you really want to design a multi-thier
> >> design (for example a 3 layer design), where
> >>
> >>                                             /  client1 (browser)
> >>  database  <--->   bussines rules           -  client2 (browser)
> >>                   (ie. apache, php,...)     \  .....
> >>
> >>
> >> if your client has direct access to the database, you design is
broken...
> >>
> >> sergio
> >>
> >>



Re: Connecting remotely - multi tier

From
"Ken J. Wright"
Date:
> In essence that is what I was asking... the possibility a Postgresql API
> that I could use, as opposed to a generalised ODBC driver.  Whether for a
> client or a middle tier, it doesn't matter.

That was your original question, and the answer is simply, use libpq.dll This
*is* the PostgreSQL API. If your windoze client app uses libpq.dll then you can
access a PostgreSQL database directly *without* the use of ODBC. The Zeos
components wrap up this functionality quite nicely for Delphi. I don't know
anything about using a .dll in VB so I can't help there, but that is just a
general VB issue that any experienced VB'er can answer.

Ken


Re: Connecting remotely - multi tier

From
"Adam Lang"
Date:
I know how to use a dll for VB, I just didn't know if there was a way to
directly access the postgresql without using ODBC.

Adam Lang
Systems Engineer
Rutgers Casualty Insurance Company
----- Original Message -----
From: "Ken J. Wright" <ken@ori-ind.com>
To: "Adam Lang" <aalang@rutgersinsurance.com>;
<pgsql-interfaces@postgresql.org>
Sent: Thursday, November 02, 2000 12:07 PM
Subject: Re: [INTERFACES] Connecting remotely - multi tier


> > In essence that is what I was asking... the possibility a Postgresql API
> > that I could use, as opposed to a generalised ODBC driver.  Whether for
a
> > client or a middle tier, it doesn't matter.
>
> That was your original question, and the answer is simply, use libpq.dll
This
> *is* the PostgreSQL API. If your windoze client app uses libpq.dll then
you can
> access a PostgreSQL database directly *without* the use of ODBC. The Zeos
> components wrap up this functionality quite nicely for Delphi. I don't
know
> anything about using a .dll in VB so I can't help there, but that is just
a
> general VB issue that any experienced VB'er can answer.
>
> Ken



Re: Connecting remotely - multi tier

From
"Sergio A. Kessler"
Date:
yes, there is a way, download the zeos components and steal the .dll
for your use ...
(I don't have the url handy rigth now)

"Adam Lang" <aalang@rutgersinsurance.com> el día Thu, 2 Nov 2000 13:07:24 
-0500, escribió:

>I know how to use a dll for VB, I just didn't know if there was a way to
>directly access the postgresql without using ODBC.