Thread: v08.02.0100 uploaded
Hi, I've uploaded builds of v08.02.0100 to ftp://ftp.postgresql.org/pub/odbc/versions. It will appear on the mirrors and the main downloads site at http://www.postgresql.org/ftp/odbc/versions/ in the next 24 hours or so. This is intended as an official, stable release. Please report any problems to the mailing list. Regards, Dave.
Dave Page schreef: > Hi, > > I've uploaded builds of v08.02.0100 to > ftp://ftp.postgresql.org/pub/odbc/versions. It will appear on the > mirrors and the main downloads site at > http://www.postgresql.org/ftp/odbc/versions/ in the next 24 hours or so. > > > This is intended as an official, stable release. Please report any > problems to the mailing list. > > Regards, Dave. > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > Hi, I have downloaded the MSI from the ftp directory mentioned above. I have done as the readme file states, and that is to uninstall the previous development snapshot (removed registiry entry's, and deleted files). When I try to install the new version I get an error of a certain file that cannot be found in the cabinet file. (See attached image) Is this something I should be looking into on my own machine, or is indeed something wrong with the installer? Changes are I'm one of the first installing this ;-) Some info: - I have downloaded and extracted the zip file with the MSI several times, thinking the zip file could be currupt, but the problem remains - I'm Running XP Pro with SP2 and all the latest updates. - ask if more info is needed. Regards, Stijn.
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Stijn Vanroye > Sent: 31 August 2006 13:11 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] v08.02.0100 uploaded > > > Hi, > > I have downloaded the MSI from the ftp directory mentioned > above. I have > done as the readme file states, and that is to uninstall the previous > development snapshot (removed registiry entry's, and deleted files). > > When I try to install the new version I get an error of a > certain file > that cannot be found in the cabinet file. (See attached image) > > Is this something I should be looking into on my own machine, or is > indeed something wrong with the installer? Changes are I'm one of the > first installing this ;-) Well, I've tested it on my day-to-day XP SP2 workstation, and a clean Windows 2000 Pro VM that I keep for testing, and both were fine. If there were some weird dependency I'd expect it to show up on the Win2K machine. What's the file it's looking for? Your attachment is missing... Regards, Dave.
> > Hi, > > > > I have downloaded the MSI from the ftp directory mentioned above. I > > have done as the readme file states, and that is to uninstall the > > previous development snapshot (removed registiry entry's, > and deleted > > files). > > > > When I try to install the new version I get an error of a > certain file > > that cannot be found in the cabinet file. (See attached image) > > > > Is this something I should be looking into on my own machine, or is > > indeed something wrong with the installer? Changes are I'm > one of the > > first installing this ;-) > > Well, I've tested it on my day-to-day XP SP2 workstation, and > a clean Windows 2000 Pro VM that I keep for testing, and both > were fine. If there were some weird dependency I'd expect it > to show up on the Win2K machine. I figured that you would have tested it, but still I find the error pretty ackward. I forgot I have some VM's here myself I can use for testing. There it installed flawlesly. I guess it's a problem on my machinethen. My guess that the previous version isn't correctly uninstalled. What I have done is removed the registry entry'sreferring to PostgreSQL in [HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI], as well as removing the installed files(dll's and such.) If I run the installer on my day2day machine I don't the usual screens with the license agreement, and which parts I wantto install, it just starts copying files immediatly. On my VM asked some questions first. Any Idea what I missed when uninstalling the dev. Snapshot on my day2day machine? I'm sorry I might have spooked you with this. Maybe an uninstaller is a good option for future releases? > What's the file it's looking for? Your attachment is missing... Oops, my bad. I guess I forgot the attachment. I've attached it to this mail. Regards, Stijn.
Attachment
> -----Original Message----- > From: Stijn Vanroye [mailto:s.vanroye@easytowork.nl] > Sent: 31 August 2006 13:51 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] v08.02.0100 uploaded > > Any Idea what I missed when uninstalling the dev. Snapshot on > my day2day machine? > > I'm sorry I might have spooked you with this. Maybe an > uninstaller is a good option for future releases? That's the problem - it will uninstall itself, you just didn't :-) In Add/Remove programs you should see a 'Remove' button, or just right-click the MSI file and select the uninstall option. Best bet is probably to grab the old MSI again, reinstall it, then uninstall it properly. Regards, Dave.
> > Any Idea what I missed when uninstalling the dev. Snapshot on my > > day2day machine? > > > > I'm sorry I might have spooked you with this. Maybe an > uninstaller is > > a good option for future releases? > > That's the problem - it will uninstall itself, you just didn't :-) > > In Add/Remove programs you should see a 'Remove' button, or > just right-click the MSI file and select the uninstall option. Oops, I read somewhere you had to remove the registry entry's and remove the binaries. While trying to do 3 things at onceI kinda jumped to conclusions on this in stead of taking a better look. I feel a bit silly now ;-) > Best bet is probably to grab the old MSI again, reinstall it, > then uninstall it properly. That indeed seems to do the trick. Everything is working fine now, I tested the new driver in my BLOB test app without anyproblems. Thanks for the help. And congrats on a job well done in the development of the ODBC driver (this goes for the other developperstoo). Regards, Stijn.
Dave Page wrote: > Best bet is probably to grab the old MSI again, reinstall it, then > uninstall it properly. I agree from my experience over the last few days that multiple installs/uninstalls seem to be benign. That's one reason why I went back all the way to testing with a v7 driver and server. The only thing I did notice is that removing any DSNs appeared to rely on still having the appropriate driver installed, I don't know what would happen if one tried to edit a DSN with a driver more recent than the one that installed it but I'm doing everything I can to play safe at present. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Mark > Morgan Lloyd > Sent: 31 August 2006 17:17 > To: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] v08.02.0100 uploaded > > Dave Page wrote: > > > Best bet is probably to grab the old MSI again, reinstall it, then > > uninstall it properly. > > I agree from my experience over the last few days that multiple > installs/uninstalls seem to be benign. That's one reason why > I went back all the > way to testing with a v7 driver and server. > > The only thing I did notice is that removing any DSNs > appeared to rely on still > having the appropriate driver installed, I don't know what > would happen if one > tried to edit a DSN with a driver more recent than the one > that installed it but > I'm doing everything I can to play safe at present. It'll ignore any settings it doesn't know about and default any new ones not in the DSN. It's quite safe as we're careful not to reuse old parameter names for new/different purposes. BTW Mark; the testing I suggested yesterday should be done with this new version of the driver. I would have mentioned that last night but I didn't realise Hiroshi would commit his last changes so quickly. Regards, Dave.
Mark Morgan Lloyd schrieb: > The only thing I did notice is that removing any DSNs appeared to rely on still > having the appropriate driver installed, I don't know what would happen if one > tried to edit a DSN with a driver more recent than the one that installed it but > I'm doing everything I can to play safe at present. You cant edit or erase a DSN in the DSN manager after the driver is removed. You can create new DSNs with the same name though. At least on Win2K one can overwrite existing but broken DSNs. You can overwrite DSNs for other DBMS. This affects only DSNs where there is no driver anymore. AFAIK this doesn't happen just by upgrades. I think I had this issue when I moved from 7.x to 8.x drivers that where in another directory, too. Wasn't there also a namechange PostgreSQL to "PostgreSQL ANSI" and "PostgreSQL Unicode"?
Hi all,
I make some tests with this new version and i notice a diference in the
behaviour about the structures of tables returned by queries trough this
version and older versions of odbc
I'm using Visual FoxPro with postgres 8.1.4.
In previous version all fields are marked to accept null values.
In this version (8.02.0100) some fields now don't accept null values, seemed
to me that now use the same definition of source table structure, like this:
CREATE TABLE test (
id serial NOT NULL,
fk_test2 int4,
field1 char(3) NOT NULL,
field2 varchar(10),
field3 date );
CREATE TABLE test2 (
id serial NOT NULL,
field4 char(3) NOT NULL,
field5 char(3) );
SELECT test.*
, test2.id as id2
, test2.field4
, test2.field5
from test LEFT OUTER JOIN test2 on test.fk_test2 = test2.id;
The fields of resultset will be now this:
id int4 NOT NULL
fk_test2 int4
field1 char(3) NOT NULL
field2 varchar(10)
field3 date
id2 int4 NOT NULL
field4 char(3) NOT NULL
field5 char(3)
with odbc version 8.01.0200 all fields accept null values.
I'm not sure about what is the correct behaviour, but this can be considered
as a bug in the new version ?
Thanks in Advance
Luiz
So your issue is that now the field types including NULL constraints match the underlying tables?
Is the change caused just from changing pgODBC driver versions, while the database version stayed the same.?
Isn't this the result we would expect if we were using psql at the command line?
I don't mean to be rude, but does your application expect a resultset where certain field never have a NULL value, but where the database design has the fields specified as nullable (no specification of NOT NULL)? For instance in your example fk_test2 is designed to allow NULL, but perhaps an application does not anticipate the possibility that NULL may be its value.
Perhaps the old behavior was a bug.
Greg Campbell ENG-ASE/Michelin US5
Lexington, South Carolina
803-951-5561, x75561
Fax: 803-951-5531
greg.campbell@us.michelin.com"luiz" <luiz@planit.com.br>
Sent by: pgsql-odbc-owner@postgresql.org 08/31/2006 14:14 |
|
Hi all,
I make some tests with this new version and i notice a diference in the
behaviour about the structures of tables returned by queries trough this
version and older versions of odbc
I'm using Visual FoxPro with postgres 8.1.4.
In previous version all fields are marked to accept null values.
In this version (8.02.0100) some fields now don't accept null values, seemed
to me that now use the same definition of source table structure, like this:
CREATE TABLE test (
id serial NOT NULL,
fk_test2 int4,
field1 char(3) NOT NULL,
field2 varchar(10),
field3 date );
CREATE TABLE test2 (
id serial NOT NULL,
field4 char(3) NOT NULL,
field5 char(3) );
SELECT test.*
, test2.id as id2
, test2.field4
, test2.field5
from test LEFT OUTER JOIN test2 on test.fk_test2 = test2.id;
The fields of resultset will be now this:
id int4 NOT NULL
fk_test2 int4
field1 char(3) NOT NULL
field2 varchar(10)
field3 date
id2 int4 NOT NULL
field4 char(3) NOT NULL
field5 char(3)
with odbc version 8.01.0200 all fields accept null values.
I'm not sure about what is the correct behaviour, but this can be considered
as a bug in the new version ?
Thanks in Advance
Luiz
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Attachment
Hi Greg
I'm sorry if I'm not can express clearly what I need to explain.
My english is litle.
In a left outer join like below, field4 may have null values when test.fk_test2 is null,
now the result is a char(3) empty field, then I presume that this is a incorrect resultset
On Thu, 31 Aug 2006 15:26:04 -0400, greg.campbell wrote
> So your issue is that now the field types including NULL constraints match the underlying tables?
> Is the change caused just from changing pgODBC driver versions, while the database version stayed the same.?
> Isn't this the result we would expect if we were using psql at the command line?
> I don't mean to be rude, but does your application expect a resultset where certain field never have a NULL value, but where the database design has the fields specified as nullable (no specification of NOT NULL)? For instance in your example fk_test2 is designed to allow NULL, but perhaps an application does not anticipate the possibility that NULL may be its value.
>
> Perhaps the old behavior was a bug.
>
> Greg Campbell ENG-ASE/Michelin US5
> Lexington, South Carolina
> 803-951-5561, x75561
> Fax: 803-951-5531
> greg.campbell@us.michelin.com
>
> "luiz" <luiz@planit.com.br>
>
>
> Hi all,
>
> I make some tests with this new version and i notice a diference in the
> behaviour about the structures of tables returned by queries trough this
> version and older versions of odbc
>
> I'm using Visual FoxPro with postgres 8.1.4.
>
> In previous version all fields are marked to accept null values.
> In this version (8.02.0100) some fields now don't accept null values, seemed
> to me that now use the same definition of source table structure, like this:
>
> CREATE TABLE test (
> id serial NOT NULL,
> fk_test2 int4,
> field1 char(3) NOT NULL,
> field2 varchar(10),
> field3 date );
>
> CREATE TABLE test2 (
> id serial NOT NULL,
> field4 char(3) NOT NULL,
> field5 char(3) );
>
> SELECT test.*
> , test2.id as id2
> , test2.field4
> , test2.field5
> from test LEFT OUTER JOIN test2 on test.fk_test2 = test2.id;
>
> The fields of resultset will be now this:
>
> id int4 NOT NULL
> fk_test2 int4
> field1 char(3) NOT NULL
> field2 varchar(10)
> field3 date
> id2 int4 NOT NULL
> field4 char(3) NOT NULL
> field5 char(3)
>
> with odbc version 8.01.0200 all fields accept null values.
>
> I'm not sure about what is the correct behaviour, but this can be considered
> as a bug in the new version ?
>
> Thanks in Advance
>
> Luiz
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
--
Plan IT Tecnologia Informatica Ltda.
I'm sorry if I'm not can express clearly what I need to explain.
My english is litle.
In a left outer join like below, field4 may have null values when test.fk_test2 is null,
now the result is a char(3) empty field, then I presume that this is a incorrect resultset
On Thu, 31 Aug 2006 15:26:04 -0400, greg.campbell wrote
> So your issue is that now the field types including NULL constraints match the underlying tables?
> Is the change caused just from changing pgODBC driver versions, while the database version stayed the same.?
> Isn't this the result we would expect if we were using psql at the command line?
> I don't mean to be rude, but does your application expect a resultset where certain field never have a NULL value, but where the database design has the fields specified as nullable (no specification of NOT NULL)? For instance in your example fk_test2 is designed to allow NULL, but perhaps an application does not anticipate the possibility that NULL may be its value.
>
> Perhaps the old behavior was a bug.
>
> Greg Campbell ENG-ASE/Michelin US5
> Lexington, South Carolina
> 803-951-5561, x75561
> Fax: 803-951-5531
> greg.campbell@us.michelin.com
>
> "luiz" <luiz@planit.com.br>
>
>
> Sent by: pgsql-odbc-owner@postgresql.org > 08/31/2006 14:14 |
|
> Hi all,
>
> I make some tests with this new version and i notice a diference in the
> behaviour about the structures of tables returned by queries trough this
> version and older versions of odbc
>
> I'm using Visual FoxPro with postgres 8.1.4.
>
> In previous version all fields are marked to accept null values.
> In this version (8.02.0100) some fields now don't accept null values, seemed
> to me that now use the same definition of source table structure, like this:
>
> CREATE TABLE test (
> id serial NOT NULL,
> fk_test2 int4,
> field1 char(3) NOT NULL,
> field2 varchar(10),
> field3 date );
>
> CREATE TABLE test2 (
> id serial NOT NULL,
> field4 char(3) NOT NULL,
> field5 char(3) );
>
> SELECT test.*
> , test2.id as id2
> , test2.field4
> , test2.field5
> from test LEFT OUTER JOIN test2 on test.fk_test2 = test2.id;
>
> The fields of resultset will be now this:
>
> id int4 NOT NULL
> fk_test2 int4
> field1 char(3) NOT NULL
> field2 varchar(10)
> field3 date
> id2 int4 NOT NULL
> field4 char(3) NOT NULL
> field5 char(3)
>
> with odbc version 8.01.0200 all fields accept null values.
>
> I'm not sure about what is the correct behaviour, but this can be considered
> as a bug in the new version ?
>
> Thanks in Advance
>
> Luiz
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
--
Plan IT Tecnologia Informatica Ltda.
luiz wrote: > Hi all, > > I make some tests with this new version and i notice a diference in the > behaviour about the structures of tables returned by queries trough this > version and older versions of odbc > > I'm using Visual FoxPro with postgres 8.1.4. > > In previous version all fields are marked to accept null values. > Yes the driver didn't check the nullabilties at all. > In this version (8.02.0100) some fields now don't accept null values, seemed > to me that now use the same definition of source table structure, like this: > > CREATE TABLE test ( > id serial NOT NULL, > fk_test2 int4, > field1 char(3) NOT NULL, > field2 varchar(10), > field3 date ); > > CREATE TABLE test2 ( > id serial NOT NULL, > field4 char(3) NOT NULL, > field5 char(3) ); > > SELECT test.* > , test2.id as id2 > , test2.field4 > , test2.field5 > from test LEFT OUTER JOIN test2 on test.fk_test2 = test2.id; > Oops outer join. It's not easy to correct it unfortunately. It's hard for the driver to kow the structure of queries because the driver doesn't analyze queries fundamentally. regards, Hiroshi Inoue
Dave Page wrote: > BTW Mark; the testing I suggested yesterday should be done with this new > version of the driver. I would have mentioned that last night but I > didn't realise Hiroshi would commit his last changes so quickly. It's OK, I'm used to you guys being on the ball. Yesterday was a bit of a slow day for me, if I don't respond to a suggestion quickly it's not because I've lost interest- I've got a fair number of other things on my plate. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Hi, Since I installed driver version 08.02.0100, I get this error when trying to configure or delete a PGSQL ODBC connection: "The Setup routines for the PostgreSQL ODBC driver could not be found. Please reinstall the driver." And then: "Component not found in the registry" Of course, I tried desinstalling and reinstalling the driver, deleting a few things from the registry by hand, and installingthe latest friver from Hiroshi Webpage, but without success... I'm running XP, and never had this kind of problem for the last 3 years...! What exactly should I delete in the registry to allow a fresh install of the driver? Thanks! --------------- Philippe Lang Attik System
Attachment
Philippe Lang wrote: > Hi, > > Since I installed driver version 08.02.0100, I get this error > when trying to configure or delete a PGSQL ODBC connection: > > "The Setup routines for the PostgreSQL ODBC driver could not > be found. Please reinstall the driver." > > And then: > > "Component not found in the registry" > > > Of course, I tried desinstalling and reinstalling the driver, > deleting a few things from the registry by hand, and > installing the latest friver from Hiroshi Webpage, but without > success... > > I'm running XP, and never had this kind of problem for the last 3 > years...! > > What exactly should I delete in the registry to allow a fresh install > of the driver? > > Thanks! Hi, Apparently, the driver name has changed. "Postgresql" has now become "Postgresql Unicode". Changing that in the registry,under "Software/ODBC.*" corrects the problem. Cheers, --------------- Philippe Lang Attik System
Attachment
Dave Page wrote: > I've uploaded builds of v08.02.0100 The docs directory has vanished from the source tarballs. -- Peter Eisentraut http://developer.postgresql.org/~petere/
On 6/9/06 19:29, "Peter Eisentraut" <peter_e@gmx.net> wrote: > Dave Page wrote: >> I've uploaded builds of v08.02.0100 > > The docs directory has vanished from the source tarballs. Rats - missing \ in the Makefile. Fixed in CVS; thanks. Regards, Dave.
> 08.02.0100 Dave, is this still the current version? http://pgfoundry.org/projects/psqlodbc/ appears to be delivering 8.02.00.02. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Mark > Morgan Lloyd > Sent: 20 September 2006 13:17 > To: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] v08.02.0100 uploaded > > > 08.02.0100 > > Dave, is this still the current version? > http://pgfoundry.org/projects/psqlodbc/ > appears to be delivering 8.02.00.02. That's under the Development Snapshots section, but yes, it is out of date so I have removed it. Thanks, Dave.
Dave Page wrote: > > Dave, is this still the current version? > > http://pgfoundry.org/projects/psqlodbc/ > > appears to be delivering 8.02.00.02. > > That's under the Development Snapshots section, but yes, it is out of > date so I have removed it. Yes, but I got there via http://www.postgresql.org/download/ which makes it more than a little confusing. OK, I'm heading back to 8.02.0100... I think the thing that was confusing me was that 0002 was showing a single "PostgreSQL" driver while 0100 has "PostgreSQL ANSI" and "PostgreSQL Unicode"- I'd forgotten which way the project was leaning on this. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]