Thread: Re: [HACKERS] Re: unixODBC again :-(

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

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.

> 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