R: ODBC 7.0006 bugs

From: "David Ciarniello" <brainlost(at)rocketmail(dot)com>
To: "Henshall, Stuart - WCP" <SHenshall(at)westcountrypublications(dot)co(dot)uk>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: R: ODBC 7.0006 bugs
Date: 2001-07-06 10:56:22
Message-ID: 002901c1060a$4c0c5200$0106010a@minosse
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

> Hello,
> 1) Could be the Jet query handler is throwing up over this. Try as a
> pass through query

it was a pass-through query.
the problem doesn't affect connection with "Parse statement" setting
disabled
(so I suppose it is the parser in the driver that causes it)

> 2) This is so that Access can tell wether some one else has altered
> the record you are working on. If you don't use row versioning it needs to
> look to see if any fields have changed (which creates the problem you
> described). Also Access can be a bit funny about text/memo fields.
> 3) I can see you're point. However I tend not to use DSN's but
> rather connection strings so its helpful to be able to turn on logging
with
> out editing the program.

Can't we move all settings on a datasource basis continuing to support
all parametrs on connection strings ?

> 4) Are you using Jet for this? Select 'Hello World'; works fine in
> psql.It also works just fine in Access query builder (although select
'hello
> world'::text doesn't). How are you entering this query? Also I believe
> typecasting by ::text is a Postgresism. I think the SQL'92 way is
> CAST('Hello World' AS text). Neither works with Access queries (AFAIK). In
> Access something like CStr('Hello World') uses the VB string conversion
> routine and should be applicable most places (NOT pass through queries
> though).

I found the problem was the parser (as point 1)

> 5) I disagree. If I'm having problems connecting I want to see all
> the options in the connection string. Don't log when you're not debugging,
> it slows everything down.

You can find the authentication response into the backend logs (like the
(in)famous "password authentication failed for user admin")
Instead somebody could activate the logger without my authorization
(consider a pc that shares the hard drive, just put the right reg file into
the startup folder and wait for the next reboot - considering win9x
stability you don't have to wait too much :-)) - so that the log can be
produced... you can grab the password from a network environment even
without ever seeing that pc).
I think it's a security risk.

In response to

Browse pgsql-odbc by date

  From Date Subject
Next Message Henshall, Stuart - WCP 2001-07-06 11:42:24 RE: ODBC 7.0006 bugs
Previous Message Henshall, Stuart - WCP 2001-07-06 08:59:55 RE: ODBC 7.0006 bugs