FW: [pgsql-www] Thanks plus three observations & some questions - Mailing list pgsql-odbc

> -----Original Message-----
> From: pgsql-www-owner@postgresql.org
> [mailto:pgsql-www-owner@postgresql.org] On Behalf Of Dave Page
> Sent: 09 February 2005 16:40
> To: Johann
> Cc: PostgreSQL WWW Mailing List
> Subject: Re: [pgsql-www] Thanks plus three observations &
> some questions
>
> [Please keep replies on-list]

Better yet, the right 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
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>