Horton

Thread

  1. Re: unixODBC again :-(

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-01-24T13:50:20Z

    Folks, I need help on this.  It would be nice to support unixODBC, but I
don't understand the ramifications of these changes.

> pgman@candle.pha.pa.us wrote:
> 
> > Nick, sorry this was never resolved.  Do have any recollection of the
> > issues involved?
> 
> Hi Bruce,
> 
> Yes I can tell you what I was changing, I would love to get the code in the unixODBC distrib to match the one you have, or even to remove it
> and point people to you.
> 
> There are a few simple changes.
> 
> 1. Add options to use unixODBC in the configure.in file, the mainly consists of finding the root of the unixODBC install prefix, and adding
> -I /unixODBC/path/include and -L /unixODBC/path/lib to the driver build
> 
> 2. Change the way the driver gets config info, to be the same as when built under windows. link with -lodbcinst and it provides
> SQLGetPrivateProfileString. the code that calls this works as long as the correct define is set.
> 
> 3. Stop calling ODBC functions in the driver, this is simple but messy, the problem being the call (say) in SQLAllocStmt that calls
> SQLAllocHandle in the driver, ends up calling the SQLAllocHandle in the driver manager.
> 
> There are a couple of other changes I have made, that you may want to add, I added the code to allow encrypted passwords (taken from the pg
> lib), as crypt is avaiable on unix. Add the option to detect a server name of localhost, and open the unix domain socket, in fact try two
> places, to handle the debian build where the location is different. Again both of these would have no place on Windows but in Unix.
> 
> Its chaos here at the moment, having lost a machine (dead disk) in the move to nice new (old building) offices in the country side, but if
> you want any help, just shout.
> 
> 
> --
> Nick Gorham
> When I die, I want to go like my grandfather did, gently while sleeping,
> and not like his passangers, screaming in a panic, looking for the
> inflatable raft. -- Seen on ./
> 
> 
> 
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  2. Re: Re: unixODBC again :-(

    Peter Eisentraut <peter_e@gmx.net> — 2001-01-24T18:15:12Z

    Bruce Momjian writes:

> > 1. Add options to use unixODBC in the configure.in file, the mainly consists of finding the root of the unixODBC install prefix, and adding
> > -I /unixODBC/path/include and -L /unixODBC/path/lib to the driver build

--with-includes, --with-libraries

> > 2. Change the way the driver gets config info, to be the same as when built under windows. link with -lodbcinst and it provides
> > SQLGetPrivateProfileString. the code that calls this works as long as the correct define is set.

I don't understand this.  The driver gets the config info just fine; why
add another way?

> > 3. Stop calling ODBC functions in the driver, this is simple but messy, the problem being the call (say) in SQLAllocStmt that calls
> > SQLAllocHandle in the driver, ends up calling the SQLAllocHandle in the driver manager.

This is fixed using magic linker options on ELF platforms.  I don't recall
how the patch tried to address this, but a better solution is probably
necessary.

> > There are a couple of other changes I have made, that you may want
> to add, I added the code to allow encrypted passwords (taken from the
> pg > lib), as crypt is avaiable on unix.

Why not.

> Add the option to detect a
> server name of localhost, and open the unix domain socket,

I don't think so.  localhost is a valid host name.

> in fact try
> two > places, to handle the debian build where the location is
> different.

We have a general approach to non-standard socket names now.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

  3. Re: Re: unixODBC again :-(

    Nick Gorham <nick@lurcher.org> — 2001-01-24T18:53:42Z

    peter_e@gmx.net wrote:

> Bruce Momjian writes:
>
> > > 1. Add options to use unixODBC in the configure.in file, the mainly consists of finding the root of the unixODBC install prefix, and adding
> > > -I /unixODBC/path/include and -L /unixODBC/path/lib to the driver build
>
> --with-includes, --with-libraries

If it works then fine, other drivers use a --with-unixODBC to enable any other changes that are needed.

> > > 2. Change the way the driver gets config info, to be the same as when built under windows. link with -lodbcinst and it provides
> > > SQLGetPrivateProfileString. the code that calls this works as long as the correct define is set.
>
> I don't understand this.  The driver gets the config info just fine; why
> add another way?

Well because the driver does not know where to get the config info from, libodbcinst.so in unixODBC provides SQLGetPrivateProfileString, the
location of user and system ini files are defined by this lib, if it doesn't do this you may have the situation where the driver manager gets
information from one ini file and the driver from a different one.

> > > 3. Stop calling ODBC functions in the driver, this is simple but messy, the problem being the call (say) in SQLAllocStmt that calls
> > > SQLAllocHandle in the driver, ends up calling the SQLAllocHandle in the driver manager.
>
> This is fixed using magic linker options on ELF platforms.  I don't recall
> how the patch tried to address this, but a better solution is probably
> necessary.

If there is a better way, please let me know, I would love to have a better solution.

> > > There are a couple of other changes I have made, that you may want
> > to add, I added the code to allow encrypted passwords (taken from the
> > pg > lib), as crypt is avaiable on unix.
>
> Why not.
>
> > Add the option to detect a
> > server name of localhost, and open the unix domain socket,
>
> I don't think so.  localhost is a valid host name.

Ok, but don't you think it is worth having some way to get it to use UNIX domain sockets instead of TCP ones, for instance if postmaster isn't
started with a -i ?

> We have a general approach to non-standard socket names now.

Great, thats a non problem then, what do you do ?

--
Nick Gorham
When I die, I want to go like my grandfather did, gently while sleeping,
and not like his passangers, screaming in a panic, looking for the
inflatable raft. -- Seen on ./

  4. Re: Re: unixODBC again :-(

    Peter Eisentraut <peter_e@gmx.net> — 2001-01-24T20:20:51Z

    Nick Gorham writes:

> Well because the driver does not know where to get the config info
> from,

Then the driver should be fixed to do that, with or without unixODBC.

> libodbcinst.so in unixODBC provides SQLGetPrivateProfileString,
> the location of user and system ini files are defined by this lib, if
> it doesn't do this you may have the situation where the driver manager
> gets information from one ini file and the driver from a different
> one.

--with-odbcinst=DIRECTORY

> > > Add the option to detect a
> > > server name of localhost, and open the unix domain socket,
> >
> > I don't think so.  localhost is a valid host name.
>
> Ok, but don't you think it is worth having some way to get it to use
> UNIX domain sockets instead of TCP ones, for instance if postmaster
> isn't started with a -i ?

Yes, that would be okay, but it's not okay to eliminate a feature to add
another one.

> > We have a general approach to non-standard socket names now.
>
> Great, thats a non problem then, what do you do ?

Pick up DEFAULT_PGSOCKET_DIR from config.h.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

  5. Re: Re: unixODBC again :-(

    Nick Gorham <nick@lurcher.org> — 2001-01-24T22:37:52Z

    peter_e@gmx.net wrote:

> Nick Gorham writes:
>
> > Well because the driver does not know where to get the config info
> > from,
>
> Then the driver should be fixed to do that, with or without unixODBC.

Well yes, but again, using the Windows situation as a model (not that
I would normally suggest windows as a role model for anything), its not the
drivers job to know or care where the info comes from, that the job of the
(a) driver manager.

> > libodbcinst.so in unixODBC provides SQLGetPrivateProfileString,
> > the location of user and system ini files are defined by this lib, if
> > it doesn't do this you may have the situation where the driver manager
> > gets information from one ini file and the driver from a different
> > one.
>
> --with-odbcinst=DIRECTORY

Yes but there are two places, the user ~/.odbc.ini directory, and the
system /sysconfdir/odbc.ini.

using the odbcinst lib, means all drivers can use the same info store, and
you can just install a binary driver without having to set any
configuration.

> > > > Add the option to detect a
> > > > server name of localhost, and open the unix domain socket,
> > >
> > > I don't think so.  localhost is a valid host name.
> >
> > Ok, but don't you think it is worth having some way to get it to use
> > UNIX domain sockets instead of TCP ones, for instance if postmaster
> > isn't started with a -i ?
>
> Yes, that would be okay, but it's not okay to eliminate a feature to add
> another one.

I would agree with that, I just did it the way I did as it fitted what some
users needed. Not sure how many people would have a network setup with
localhost set in dns to point to another machine, Though I agree there is
no reason why you couldn't do it.

> > > We have a general approach to non-standard socket names now.
> >
> > Great, thats a non problem then, what do you do ?
>
> Pick up DEFAULT_PGSOCKET_DIR from config.h.

Thats ok, but if I was to keep a driver in unixODBC distrib, I would have
to have a --postgres-socket= option in the config, same problem with
odbcinst but in reverse. Maybe no simple answer to that one.

All I do at the moment, is have the driver try the two places it knows
about, maybe it should be in the ini file, perhaps if the socket_location
is set it would connect via that. It would fix the problem with using
localhost to switch the connection method.

--
Nick Gorham
When I die, I want to go like my grandfather did, gently while sleeping,
and not like his passangers, screaming in a panic, looking for the
inflatable raft. -- Seen on ./

  6. Re: Re: unixODBC again :-(

    Bruce Momjian <pgman@candle.pha.pa.us> — 2001-01-24T23:47:33Z

    Glad these items are being resolved.  THis has sat around too long. 
Please keep discussing and come up with a good patch.  We will help
however we can.


> peter_e@gmx.net wrote:
> 
> > Nick Gorham writes:
> >
> > > Well because the driver does not know where to get the config info
> > > from,
> >
> > Then the driver should be fixed to do that, with or without unixODBC.
> 
> Well yes, but again, using the Windows situation as a model (not that
> I would normally suggest windows as a role model for anything), its not the
> drivers job to know or care where the info comes from, that the job of the
> (a) driver manager.
> 
> > > libodbcinst.so in unixODBC provides SQLGetPrivateProfileString,
> > > the location of user and system ini files are defined by this lib, if
> > > it doesn't do this you may have the situation where the driver manager
> > > gets information from one ini file and the driver from a different
> > > one.
> >
> > --with-odbcinst=DIRECTORY
> 
> Yes but there are two places, the user ~/.odbc.ini directory, and the
> system /sysconfdir/odbc.ini.
> 
> using the odbcinst lib, means all drivers can use the same info store, and
> you can just install a binary driver without having to set any
> configuration.
> 
> > > > > Add the option to detect a
> > > > > server name of localhost, and open the unix domain socket,
> > > >
> > > > I don't think so.  localhost is a valid host name.
> > >
> > > Ok, but don't you think it is worth having some way to get it to use
> > > UNIX domain sockets instead of TCP ones, for instance if postmaster
> > > isn't started with a -i ?
> >
> > Yes, that would be okay, but it's not okay to eliminate a feature to add
> > another one.
> 
> I would agree with that, I just did it the way I did as it fitted what some
> users needed. Not sure how many people would have a network setup with
> localhost set in dns to point to another machine, Though I agree there is
> no reason why you couldn't do it.
> 
> > > > We have a general approach to non-standard socket names now.
> > >
> > > Great, thats a non problem then, what do you do ?
> >
> > Pick up DEFAULT_PGSOCKET_DIR from config.h.
> 
> Thats ok, but if I was to keep a driver in unixODBC distrib, I would have
> to have a --postgres-socket= option in the config, same problem with
> odbcinst but in reverse. Maybe no simple answer to that one.
> 
> All I do at the moment, is have the driver try the two places it knows
> about, maybe it should be in the ini file, perhaps if the socket_location
> is set it would connect via that. It would fix the problem with using
> localhost to switch the connection method.
> 
> --
> Nick Gorham
> When I die, I want to go like my grandfather did, gently while sleeping,
> and not like his passangers, screaming in a panic, looking for the
> inflatable raft. -- Seen on ./
> 
> 
> 
> 


-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

  7. serial values and odbc

    Alfonso Peniche <alfonso@iteso.mx> — 2001-01-25T15:46:14Z

    I am working with delphi through odbc to get to Postgres, but I have a
problem:

Everytime I try to make an insertion, I get a message from the odbc driver
saying a Primary key value cannot be null (which is on purpose since I want
postgres to use it serial value properties). Can anyone tell me if there's
something special I have to do on the ODBC configuration, or how do I make an
insertion through odbc?

Thanx.

  8. Re: serial values and odbc

    Tibor Laszlo <ltibor@mail.tiszanet.hu> — 2001-01-26T17:30:38Z

    > I am working with delphi through odbc to get to Postgres, but I have a
> problem:
> 
> Everytime I try to make an insertion, I get a message from the odbc driver
> saying a Primary key value cannot be null (which is on purpose since I want
> postgres to use it serial value properties). Can anyone tell me if there's
> something special I have to do on the ODBC configuration, or how do I make an
> insertion through odbc?

I think it isn't ODBC related. But we use the following method:

Wth the DataSet's OnBeforPost method fetch the serial's NextValue and fill in
the Field in the DataSet like this:

QueryBeforPost(TDataSet* DaraSet)
{
  if (DataSet->State == dsInsert && 
       DataSet->FieldByName("<MySerialField">)->Value == Null)
  {
    TQuery* q = new TQuery(this);
    q->DataBaseName = "<MyBDEDataBaseAliasName>";
    q->SQL->Clear();
    q->SQL->Add("SELECT nextval('<MyTable><MySerialField>_seq'");
 
   // put these two statments into a try block...
   q->Active = true;
    DatSet->FieldByName("<MySerialField>")->Value =
      q->FieldByName("nextval")->Value;

    q->Active = false;
    delete q;
  }
}

Sorry, I'm a C++ programmer, so I can't write ObjectPascal code but I think it
will help.

This is the recommended method with PostgreSQL and with visual database
actions. You may put this code without the dsInsert condition into the
BeforInsert event to show the user the value but we prefer the one shown.

If the post fails - or the user cancels - the next nextval will send (the
next) safe value (see docs and archive). No matter the unused values. It works
even in a transaction block.

-- 
Tibor Laszlo
ltibor@mail.tiszanet.hu