Re: Thanks plus three observations & some questions - Mailing list pgsql-www

From Dave Page
Subject Re: Thanks plus three observations & some questions
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4528A47@ratbert.vale-housing.co.uk
Whole thread Raw
List pgsql-www
[Please keep replies on-list]

> -----Original Message-----
> From: Johann [mailto:johann@tygerpos.com]
> Sent: 09 February 2005 16:20
> To: Dave Page
> Subject: Thanks plus three observations & some questions
>
> Hi,
>
> Thanks for the comment - that second, unqualified query seems
> like really
> odd behavior.  If the driver has any control over that query,
> maybe it
> could add a " where 1 = 0" clause - hopefully the optimizer
> would recognize
> that.

The driver (afaik) just sees a query from the app. It will have no way
of knowing what that query is for.

> I'm running the version that shipped with the latest
> PostgreSQL (8.0.1) -
> is that the latest?

The latest snapshot, yes.

> Here's a peculiar issue: On a VB form with bound variables,
> tablename in DB
> is in lower case - if you set adodc1.recordsource="SELECT * FROM
> MixedCaseTablename" - the bound variables are displayed, but
> you get an
> error when you adodc1.recordset.updatebatch.  Change
> tablename to lower
> case and everything works right.

Always quote mixed case names and you /shouldn't/ get a problem. Avoid
them altogether and life will be a lot happier :-)

> Another peculiarity: In the Reposition event on DAO control,
> the items in
> user controls have already been synched with the recordset, so if you
> reference TB_USERNAME.TEXT, you'll get the right username.  Under ADO
> MoveComplete event, that's not true, you have to reference
> adodc1.recordset!fieldname directly.  Don't know if that's
> the driver or
> DAO vs ADO.

I vaguely remember seeing this issue in the past, but I don't recall the
details. Unfortunately I don't have time to investigate at the moment,
but I would very surprised if that wasn't a Microsoftism.

> Another one: If you have a bound label and set it to a new
> value with code,
> it won't be posted to the DB on .updatebatch.  If you update
> the label and
> an additional textbox by clicking/typing, both the textbox
> and the label
> will be posted to the DB.  This appears to be true for
> several control
> types - set by code, no update, set by hand anything on
> screen, all updates
> posted.

Yes, I've seen this one as well - the controls only tell the data
control about changes that are made through the UI. Another Microsoftism
unfortunately.

> Is there a FAQ I should reference that would tell me about
> stuff like this?

There is a faq on the Gborg site
(http://gborg.postgresql.org/project/psqlodbc), but it doesn't contain
answers to your questions iirc.

> Is there a freeware tool to convert Access -> PostgreSQL, including
> generating cascading update/delete rules?  I've roughed one
> in, works for
> my 155-table DB, wonder if anyone would like it.  It's in
> VB6.  Doesn't do
> the reports, just the tables, indexes, and relations.  Dumb naming
> convention for indexes & relations, handles most but not all
> types.  Generates SQL, but could directly update with very little
> effort.  Three output files: tables/index DDL, inserts DML, relations
> DDL.  Converts keywords, but list is presently hard coded [role ->
> rolename, class -> classname, and a few others I ran into.]

There was a migration wizard in pgAdmin II, but it didn't do rules
either. I'm sure others would find you tool handy though - perhaps you
could create a project on pgfoundry.org and share it?

Regards, Dave

pgsql-www by date:

Previous
From: "Dave Page"
Date:
Subject: Re: [ODBC] New release
Next
From: "Dave Page"
Date:
Subject: Re: Thanks plus three observations & some questions