Thread: New driver snapshot - 07.03.0209
Hi all, I have just uploaded a new snapshot of the driver to the PostgreSQL FTP server (ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/). This is version 07.03.0209 and includes the odd few fixes that Bruce and I have worked on recently. It is mainly intended to show the current status of the driver and start generating a little feedback so we know where we are. It might take a day or so to propagate to the front end servers... In addition, I have also modified the makefiles, installer and source such that there is now only one version of the driver: Driver name: PostgreSQL File name: psqlodbc.dll ODBC level: 3.0 Unicode support: Yes The *nix makefiles are currently untouched (apart from the removal of a few old files and the version number tweak). The snapshot on the ftp site contains just the driver DLL file and the .reg file to install it on Windows. I haven't created a source tarball - if anyone wants one, please chackout the psqlodbc module from the project CVS, using the REL-07_03_0209 tag. Regards, Dave. PS. Please don't send me any bug reports directly - as I've made clear, I will help manage the project but don't currently have time for development work due to other commitments.
I gave the 7.3.2.9 driver a whirl. The first thing that I notice is that some characters aren't displayed as they used to be... For instance �testing� yields ?esting? ... This is presumably due to the use of the unicode driver as the new standard driver. That shouldn't be a problem. There's probably a setting that I'm missing. I've tried using the set client_ecnoding='SQL_ASCII' in the connection string without any effect. CG --- Dave Page <dpage@vale-housing.co.uk> wrote: > Hi all, > > I have just uploaded a new snapshot of the driver to the PostgreSQL FTP > server (ftp://ftp.postgresql.org/pub/odbc/versions/snapshots/). This is > version 07.03.0209 and includes the odd few fixes that Bruce and I have > worked on recently. It is mainly intended to show the current status of > the driver and start generating a little feedback so we know where we > are. It might take a day or so to propagate to the front end servers... > > In addition, I have also modified the makefiles, installer and source > such that there is now only one version of the driver: > > Driver name: PostgreSQL > File name: psqlodbc.dll > ODBC level: 3.0 > Unicode support: Yes > > The *nix makefiles are currently untouched (apart from the removal of a > few old files and the version number tweak). > > The snapshot on the ftp site contains just the driver DLL file and the > .reg file to install it on Windows. I haven't created a source tarball - > if anyone wants one, please chackout the psqlodbc module from the > project CVS, using the REL-07_03_0209 tag. > > Regards, Dave. > > PS. Please don't send me any bug reports directly - as I've made clear, > I will help manage the project but don't currently have time for > development work due to other commitments. > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html
> -----Original Message----- > From: Chris Gamache [mailto:cgg007@yahoo.com] > Sent: 14 April 2004 16:06 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] New driver snapshot - 07.03.0209 > > I gave the 7.3.2.9 driver a whirl. The first thing that I > notice is that some characters aren't displayed as they used > to be... For instance "testing" yields > > ?esting? ... This is presumably due to the use of the unicode > driver as the new standard driver. That shouldn't be a > problem. There's probably a setting that I'm missing. I've > tried using the set client_ecnoding='SQL_ASCII' in the > connection string without any effect. What's the server encoding? I'm not seeing any problems here with SQL_ASCII at both ends.... Regards Dave.
Its SQL_ASCII at both ends here too. The characters in question are the literal representation of “ ” ... Yahoo! Mail may have translated those characters in my email to plain ol' double-quotes, which are benign. CG --- Dave Page <dpage@vale-housing.co.uk> wrote: > > > > -----Original Message----- > > From: Chris Gamache [mailto:cgg007@yahoo.com] > > Sent: 14 April 2004 16:06 > > To: Dave Page; pgsql-odbc@postgresql.org > > Subject: Re: [ODBC] New driver snapshot - 07.03.0209 > > > > I gave the 7.3.2.9 driver a whirl. The first thing that I > > notice is that some characters aren't displayed as they used > > to be... For instance "testing" yields > > > > ?esting? ... This is presumably due to the use of the unicode > > driver as the new standard driver. That shouldn't be a > > problem. There's probably a setting that I'm missing. I've > > tried using the set client_ecnoding='SQL_ASCII' in the > > connection string without any effect. > > What's the server encoding? I'm not seeing any problems here with > SQL_ASCII at both ends.... > > Regards Dave. __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html
> -----Original Message----- > From: Chris Gamache [mailto:cgg007@yahoo.com] > Sent: 14 April 2004 18:02 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] New driver snapshot - 07.03.0209 > > Its SQL_ASCII at both ends here too. > > The characters in question are the literal representation of > “ ” ... Yahoo! Mail may have translated those > characters in my email to plain ol' > double-quotes, which are benign. That'll be the problem then. SQL_ASCII is only 7 bit ASCII safe (iirc) which those characters are certainly not. I'm the last person you want to ask about charactersets etc, but my guess is that you'll need to use UNICODE to /properly/ work with characters such as these. Regards, Dave.
--- Dave Page <dpage@vale-housing.co.uk> wrote: > > That'll be the problem then. SQL_ASCII is only 7 bit ASCII safe (iirc) > which those characters are certainly not. I'm the last person you want > to ask about charactersets etc, but my guess is that you'll need to use > UNICODE to /properly/ work with characters such as these. You're the second-to-last person who should be asked about character sets. :) I wonder why those characters appear properly using the 7.03.02.00 driver? Was it incorrect behavior? There were three drivers that came standard in the PostgreSQL MSI installer, the Standard 3.0 driver, the Legacy Driver, and the Beta-Unicode driver. I was using the standard driver. If it didn't support the extended ASCII characters, I wonder how those characters got inserted in the first place? I guess what I'm getting at is 7.03.02.00 DOES behave differently than 7.03.02.09 in this situation. I don't know with which driver there was a problem, old or new. This might matter, and I only brought it up because you were asking for feedback on testing of the new ODBC driver. CG CG __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html
> -----Original Message----- > From: Chris Gamache [mailto:cgg007@yahoo.com] > Sent: 16 April 2004 14:59 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: RE: [ODBC] New driver snapshot - 07.03.0209 > > > I guess what I'm getting at is 7.03.02.00 DOES behave differently than > 7.03.02.09 in this situation. I don't know with which driver > there was a problem, old or new. My understanding is that sometimes non-multibyte code will work with multibyte characters depending on how the app interprets the data. We saw this in pgAdmin II which could often insert characters like umlauts into an SQL_ASCII database, which then failed with pgAdmin III which has full-blown Unicode support and refused to read the 'broken' characters. In that case the answer was to use Unicode or Latin1 iirc. > This might matter, and I > only brought it up because you were asking for feedback on > testing of the new ODBC driver. All feedback is good :-) Regards, Dave.
> -----Original Message-----
> From: Philippe Lang [mailto:philippe.lang@attiksystem.ch]
> Sent: 19 April 2004 08:57
> To: Dave Page
> Subject: RE: [ODBC] New driver snapshot - 07.03.0209
>
> Hello,
>
> After a quick test, I would say the driver works fine,
> thanks. I use a LATIN1 encoded database, though.
Thanks for the feedback.
> Regarding the issue we have been talking about in this
> newsgroup, the "SELECT @@IDENTITY" problem, is there a way of
> incorporing that in the driver itself? Your mention in your
> last message:
>
> > Standard answer: The best method would be to do a "SELECT
> currval('seq_name');"
> > when required on the relevant sequence.
>
> Are you talking about a sequence in the driver? Could you
> point me to the place where you beleive changes could be
> made? I could make a few tests here, but I have to say I
> absolutely don't know where to start, nor if it's possible to
> fix the driver...
It's more of an app-level thing. There are various problems to consider:
- The sequence must be identified - that means executing a query to look
at the schema and figure out what sequence is generating the ID (if
any).
- What if the pkey is multi-part?
- What if you ignore pkeys, and look for columns with a default of
nextval(something or other) - what if there are 2? Which one should you
return?
- How do you identify an insert in the driver? Do you need to parse
*every* statement, or will this only work for cursors (which I never use
and cannot help much with).
Doing this properly requires changes to the fe/be protocol imho. If the
CommandComplete message could be changed to return the pkey values for
any affected rows, that would be ideal at first thought (though anything
more than a couple of records should probably have a dedicated query
message to prevent unnecessary data transfers). 2 problems there though
- firstly, Tom just changed the fe/be protocol for 7.4 and I seriously
doubt he (or any of the other hackers) would want it to change again,
and secondly, the driver doesn't even support the 7.4 protocol yet
(though Hiroshi did mention he had a patch once), never mind a future
version.
I think this is a non-starter :-(
Regards, Dave.