Postgresql odbc and Visual studio 2005 .net 2.0

Dave briljant!

The dll’s enable VS to autogenerate tables schema’s etc...

I’ll inform MS and the people who might have similar problems and are following the bugreport at MS forums.

Cheers,

Paul

P.S. If you happen to come over to the Netherlands sometime soon I’ll buy you a beer.

OK, trying again (Google bounced it). You'll need to rename the attachment to dlls.zip.

Regards, Dave

 

---

From: Dave Page
Sent: 24 November 2005 13:13
To: 'Leendert Paul Diterwich'
Subject: RE: Postgresql odbc and Visual studio 2005 .net 2.0

Hi Paul

 

The update is attached. Please copy the enclosed DLLs over your existing copies.

 

Please let me know if it fixes the problem.

 

Regards, Dave

 

---

From: Leendert Paul Diterwich [mailto:paulditerwich@gmail.com]
Sent: 24 November 2005 12:57
To: Dave Page
Subject: RE: Postgresql odbc and Visual studio 2005 .net 2.0

If its no problem for you, I would appreciate that very much!

 

Regards,

 

Paul

 

---

Van: Dave Page [mailto:dpage@vale-housing.co.uk]
Verzonden: donderdag 24 november 2005 12:49
Aan: Leendert Paul Diterwich; pgsql-odbc@postgresql.org
Onderwerp: RE: Postgresql odbc and Visual studio 2005 .net 2.0

 

 

 

---

From: Leendert Paul Diterwich [mailto:paulditerwich@gmail.com]
Sent: 23 November 2005 16:53
To: pgsql-odbc@postgresql.org
Cc: Dave Page
Subject: Postgresql odbc and Visual studio 2005 .net 2.0

Hi all,

 

I just got word from MS and this is what they said about the problems some of us are experiencing:

 

Hi Paul,

It appears that there are problems with this particular ODBC driver. It tells us that the default catalog is "\0\0" (taken from the IDbConnection.Database property) so we pass this as a catalog restriction to enumerate tables. This works, however the rows returned provide a catalog of NULL. This is inconsistent behavior, and when we then ask our cache to select objects with the catalog restriction "\0\0" it finds none because all objects in the cache have a NULL catalog.

There is no workaround for this issue, unfortunately. The only solution is for the ODBC driver to be fixed.

Thanks,
Stephen Provine
VS Data Development Team

 

Is it possible to change the behavior of the ODBC driver?

 

Certainly, if we can track down the actual bug. The problem is, afaik, there is no way to ask an ODBC driver what the default catalog is, so I'm not sure where they're getting this info from. If they're actually querying the /current/ catalog immediately following a connect, then they're using SQLGetConnectAttr, in which I have just commited a fix which meant that the wrong result length was returned. That could conceivably have caused this problem.

 

I can email a couple of DLL's to test if you like?

 

Regards, Dave.