Обсуждение: int8 becames string in BDE :-(

Dear Hiroshi and Tom,

I downloaded the latest psqlodbc.dll for PostgreSQL 7.2.1. My problem is I
should migrate from 7.1.3 to 7.2.1 because I need "CREATE OR REPLACE
FUNCTION", but COUNT(*) returns int8 now. Unfortunately, Borland Database
Engine and/or ODBCExpress (from Korbitec Pty.) understands int8 as string.

I looked at the code for some minutes but I haven't found the appropriate
place in the ODBC driver if it's possible to convert all int8 data into
int4. In file HISTORY I can see that "SUM(), AVG() and COUNT() now returns
int8 for speed" from version 7.2. So, I can see no solution to switch this
feature off at the server side---is there a possibility at the ODBC driver
side?

TIA, Zoltan

--
                         Kov\'acs, Zolt\'an
                         kovacsz@pc10.radnoti-szeged.sulinet.hu
                         http://www.math.u-szeged.hu/~kovzol
                         ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz

Kovacs Zoltan wrote:
>
> Dear Hiroshi and Tom,
>
> I downloaded the latest psqlodbc.dll for PostgreSQL 7.2.1.
> My problem is I
> should migrate from 7.1.3 to 7.2.1 because I need "CREATE OR REPLACE
> FUNCTION", but COUNT(*) returns int8 now. Unfortunately,
> Borland Database
> Engine and/or ODBCExpress (from Korbitec Pty.) understands
> int8 as string.

Is it the true cause ?
Isn't it because of the current driver's behavior that
returns SQL_VARCHAR for int8 ? OTOH certainly there are
some applications which can't handle SQL_BIGINT.
Recently I changed the driver to return SQL_NUMERIC
for int8 with Microsoft-jet and it seems to work.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

On Wed, 29 May 2002, Hiroshi Inoue wrote:

> Kovacs Zoltan wrote:
> >
> > Dear Hiroshi and Tom,
> >
> > I downloaded the latest psqlodbc.dll for PostgreSQL 7.2.1.
> > My problem is I
> > should migrate from 7.1.3 to 7.2.1 because I need "CREATE OR REPLACE
> > FUNCTION", but COUNT(*) returns int8 now. Unfortunately,
> > Borland Database
> > Engine and/or ODBCExpress (from Korbitec Pty.) understands
> > int8 as string.
>
> Is it the true cause ?
> Isn't it because of the current driver's behavior that
> returns SQL_VARCHAR for int8 ? OTOH certainly there are
> some applications which can't handle SQL_BIGINT.
> Recently I changed the driver to return SQL_NUMERIC
> for int8 with Microsoft-jet and it seems to work.

Where can I check for the setting? Can I adjust it in the "Driver" menu?
I'm using version 07_02_0001, announced on 15th April.

Thanks, Zoltan

--
                         Kov\'acs, Zolt\'an
                         kovacsz@pc10.radnoti-szeged.sulinet.hu
                         http://www.math.u-szeged.hu/~kovzol
                         ftp://pc10.radnoti-szeged.sulinet.hu/home/kovacsz

Signed as Tibor, I am Gabor, co-worker of Zoltan.
(sorry to use this confusing way, but I'm not a member of this list just
popped in to help them)

Further experiments I did today: downloaded Hiroshi's 7.2.0.2 driver from a
page mentioned earlier and found the following:

----------------

1a with psqlodbc.dll (ODBC ver 2.5) BDE found count() to be a non-numeric
value (deducted from the fact that BDE aligned it to the left in the grid
and that OE complained about Integer<->String incompatibility)
1b with psqlodbc30.dll (ODBC ver 3) BDE found count() to be numeric (found
out that it's Largeint by setting a fake TIntegerField type to a "count() as
xxx" field. Changing field type to TLargeintField, it worked.)

2a using int4(count()), managed to work around the problem with ODBC 2.5,
but it is inconvenient and ugly since there are hundreds of source files in
our projects.
2b with psqlodbcl30 we could use a Largeint field type instead, which is
good, but at the first try, a certain action caused Access Violation within
psqlodbc30.dll itself. I can send the structure of this query if it helps.

3b Turned off "(Trial) Updatable Cursors" (it was checked in this new
installation of psqlodbc30.dll while it was unchecked in all the other
DSN's) in DataSource options, and now the EXEcutable sends a different
error, _earlier_, stating

[Microsoft][ODBC driver manager] Fetch type out of range

My current driver settings:
Driver. Disable GenOpt, KSQO, CommLog; Unknown Sizes=Maximum; Text As
LongVarChar
DataSource: LF-CRLF convert; protocol=7.X/6.4. As I mentioned in 2b, this
error wasn't an issue but a different error occured later with "Updatable
Cursors" checked.

The code that caused the Fetch error is a Borland code, if you are
interested in Delphi...

    if not VarIsNull(FKeyValue) and FListLink.DataSet.Active and
      FListLink.DataSet.Locate(FKeyFieldName, FKeyValue, []) then

... where FKeyValue is indeed an integer value, DataSet is indeed an open
dataset, (Active is true), and FKeyFieldName is indeed a key field of the
dataset. Again, with the old drivers (Updatable Cursors UNchecked), this
wasn't a problem, neither with the new driver (Updatable Cursors checked) .
If it helps, I can send you the query causing this problem, too.

-------------

Searching the web, I found two tips, will check them out:
(i) http://archives.postgresql.org/pgsql-interfaces/1998-10/msg00170.php :
Well, my previous problem ('[Microsoft][ODBC driver manager] Fetch type out
of range') dissappear when I changed the option hStmt -> CursorType from
Keyset Driven to Static.
... but it mentions other problems and reveals that it's Borland C++Builder
3 while we use BCB5

(ii) http://support.microsoft.com/default.aspx?scid=kb;EN-US;q141171 :
PRB: RDO Forward-Only Cursor Doesn't Allow MoveLast (Q141171)
... but this applies to MS Visual Basic Enterprise 4.0 only.

BTW, I found MS Jet to be a DLL. Call me a lamer but how can you invoke this
DLL? (if it is what you used to change the return value) Shall I install MS
Access?

Yours,
Gabor

> -----Original Message-----
> From: Kovacs Zoltan
> Sent: Wednesday, May 29, 2002 9:02 AM
>
> On Wed, 29 May 2002, Hiroshi Inoue wrote:
>
> > Kovacs Zoltan wrote:
> > >
> > > Dear Hiroshi and Tom,
> > >
> > > I downloaded the latest psqlodbc.dll for PostgreSQL 7.2.1.
> > > My problem is I
> > > should migrate from 7.1.3 to 7.2.1 because I need "CREATE OR REPLACE
> > > FUNCTION", but COUNT(*) returns int8 now. Unfortunately,
> > > Borland Database
> > > Engine and/or ODBCExpress (from Korbitec Pty.) understands
> > > int8 as string.
> >
> > Is it the true cause ?
> > Isn't it because of the current driver's behavior that
> > returns SQL_VARCHAR for int8 ? OTOH certainly there are
> > some applications which can't handle SQL_BIGINT.
> > Recently I changed the driver to return SQL_NUMERIC
> > for int8 with Microsoft-jet and it seems to work.
>
> Where can I check for the setting? Can I adjust it in the "Driver" menu?
> I'm using version 07_02_0001, announced on 15th April.
>
> Thanks, Zoltan

Laszlo Tibor wrote:
>
> Signed as Tibor, I am Gabor, co-worker of Zoltan.
> (sorry to use this confusing way, but I'm not a member of this
> list justpopped in to help them)
>
> Further experiments I did today: downloaded Hiroshi's 7.2.0.2
> driver from a page mentioned earlier and found the following:

> 1a with psqlodbc.dll (ODBC ver 2.5) BDE found count() to be a
> non-numeric value (deducted from the fact that BDE aligned it
> to the left in the grid and that OE complained about Integer
> <->String incompatibility)
> 1b with psqlodbc30.dll (ODBC ver 3) BDE found count() to be
> numeric (found out that it's Largeint by setting a fake
> TIntegerField type to a "count() as xxx" field. Changing
> field type to TLargeintField, it worked.)
> 2a using int4(count()), managed to work around the problem
> with ODBC 2.5, but it is inconvenient and ugly since there
> are hundreds of source files in our projects.

Hmm I'm now inclined to add an option to specify how
to handle int8.
  int8 -> auto(current), SQL_BIGINT, SQL_NUMERIC, SQL_VARCHAR ...
Comments ?

> 2b with psqlodbcl30 we could use a Largeint field type instead,
> which is good, but at the first try, a certain action caused
> Access Violation within psqlodbc30.dll itself. I can send the
> structure of this query if it helps.

Please send it to me.

> 3b Turned off "(Trial) Updatable Cursors" (it was checked in this new
> installation of psqlodbc30.dll while it was unchecked in all the other
> DSN's) in DataSource options, and now the EXEcutable sends a different
> error, _earlier_, stating
>
> [Microsoft][ODBC driver manager] Fetch type out of range

I've just changed the driver at http://w2422.nsk.ne.jp/~inoue/.
Please try.

> Again, with the old drivers (Updatable Cursors UNchecked),
> this wasn't a problem, neither with the new driver (Updatable
> Cursors checked).

Does this mean the old driver with Undatable cursors checked
have a problem ?

> If it helps, I can send you the query causing
> this problem, too.

Please send it to me.

> BTW, I found MS Jet to be a DLL. Call me a lamer but how can
> you invoke this
> DLL? (if it is what you used to change the return value) Shall
> I install MS
> Access?

The driver could know if the client is MS-Jet because
MS-Jet calls SQLSetConnnectAttr with the option
30002 and the parameter "Microsoft Jet".

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 30 May 2002 05:57
> To: Laszlo Tibor
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Hmm I'm now inclined to add an option to specify how
> to handle int8.
>   int8 -> auto(current), SQL_BIGINT, SQL_NUMERIC, SQL_VARCHAR
> ... Comments ?

Ugh, more options. In this particular case I think it's probably
justified purely because both Microsoft & Borland technologies have
trouble following the spec to the letter (they are after all, probably
the 2 most used developer toolsets on Win32).

I do think the current amount of options is becoming cumbersome though.
Perhaps we can get rid of a few at some point, for example:

Disable GEQO - Is this still required? Presumably the optimiser is
somewhat better now.
KSQO - is not in 7.2 or 7.1 and will probably be completely removed for
7.3 (see thread on pgsql-hackers).
Recognize Unique Indexes - Is there any reason not to do this?
SysTable Prefixes - only pg_ has been used to my knowledge since 6.3.

I personally think *all* options should also be Datasource, not Driver
related. I know Hiroshi added the 'Default' option to the Driver
dialogue, but I know from speaking to others that it's not obvious to
everyone what that means.

Just my $0.02....

Regards, Dave.

Dave Page wrote:
>
> > -----Original Message-----
> > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> >
> > Hmm I'm now inclined to add an option to specify how
> > to handle int8.
> >   int8 -> auto(current), SQL_BIGINT, SQL_NUMERIC, SQL_VARCHAR
> > ... Comments ?
>
> Ugh, more options. In this particular case I think it's probably
> justified purely because both Microsoft & Borland technologies have
> trouble following the spec to the letter (they are after all, probably
> the 2 most used developer toolsets on Win32).
>
> I do think the current amount of options is becoming cumbersome though.
> Perhaps we can get rid of a few at some point, for example:

OK I would consider it later.

> I personally think *all* options should also be Datasource, not Driver
> related. I know Hiroshi added the 'Default' option to the Driver
> dialogue, but I know from speaking to others that it's not obvious to
> everyone what that means.

OK I reorganized the dialog and add a new option *Int8 As*.
Please try the dll at http://w2422.nsk.ne.jp/~inoue/
and let me know how to improve it.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 31 May 2002 07:36
> To: Dave Page
> Cc: Laszlo Tibor; pgsql-odbc@postgresql.org; Vidas Makauskas
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> OK I reorganized the dialog and add a new option *Int8 As*.
> Please try the dll at http://w2422.nsk.ne.jp/~inoue/ and let
> me know how to improve it.

So, as I understand it:

- Click default to modify the default settings for *new* datasources.
- On the Datasource dialogue, click the Default button to return all
settings to the current defaults,

That makes a little more sense to me. I do have a couple of suggestions
though:

- Can we use a tabset rather than next/previous page buttons (which
vanish when you click the defaults button!). I think it would make a far
cleaner (and standard) interface.

- On the Default settings dialogue, the Default buton is still visible
but loads junk values. Perhaps it should load 'factory' default
settings.

- On the Default settings dialogue, how about adding an additional
warning just to make it extra clear that it is the default settings that
are being modified & not the datasource.


Regards, Dave.

Gabor again.

> -----Original Message-----
> From: Dave Page
> Sent: Friday, May 31, 2002 9:30 AM

> - Can we use a tabset rather than next/previous page buttons (which
> vanish when you click the defaults button!). I think it would make a far
> cleaner (and standard) interface.

Also, changing one page and then turning to the other page cancels the
changes (unless you press OK and DataSource again). Perhaps an Apply button
could help, and tab sheets, too.

Another thing: on the web page, you refer to 7.2.0001, though the DLL claims
itself to be 7.2.0002. Which is the truth? :)

To Hiroshi: As for the SQL queries I mentioned earlier, I'll send them ASAP
(if still needed--see below). You asked for a clarification to which I wish
to reflect here:

> > Again, with the old drivers (Updatable Cursors UNchecked),
> > this wasn't a problem, neither with the new driver (Updatable
> > Cursors checked).
>
> Does this mean the old driver with Undatable cursors checked
> have a problem ?

I haven't tried this. All I wanted to say that the behaviour of updatable
cursors unchecked did change, in our case, not in a favourable way.

As for the Field Type out of range errors: one of the two tips I mentioned
seemed to work; namely, I changed all the dataset cursortypes from
Forward-only and Keyset-driven to Static. No more errors. With the new
driver, re-tried the combinations.

Tried to change Recognize Unique Indexes and Updatable Cursors (all four
variations), since these are that we use different from the default. Effect
with the current driver:
Forward-only: Received several messages stating "Fetch type for
PGAPI_ExtendedFetch isn't allowed with ForwardOnly cursor." The associated
combobox came up, seeming to be empty. Trying to open the box, I received
the "out of range" exception.
Keyset driven: no error.

All that changed since the last state is that I could not reproduce the
Access Violation with Updatable Cursors checked. In the first place, I
didn't even get that far, only with the Keyset driven setting, but I did not
experience any more errors.

The errors were associated mostly, if not in all of the cases, with
DBLookupComboBoxes, if it helps. Based on that, I don't think it's due to
the query or the driver; I'd say it's more likely to be something closer to
the user, i.e. ODBCExpress or BCB, though I'd rule the latter out even
though it seems to be a component-related problem (VCL).

Yours,
Gabor

Laszlo Tibor wrote:
>
> Gabor again.
>
> > -----Original Message-----
> > From: Dave Page
> > Sent: Friday, May 31, 2002 9:30 AM
>
> > - Can we use a tabset rather than next/previous page buttons
> > (which vanish when you click the defaults button!). I think
> > it would make a far cleaner (and standard) interface.

Maybe but I'm not good at Windows GUI programming using C
unfortunately. I've mainly used C++(MFC) in GUI programming.

> Also, changing one page and then turning to the other page
> cancels the changes (unless you press OK and DataSource again).
> Perhaps an Apply button could help, and tab sheets, too.

Oh you are right. I've changed the dialog a little.
Please check the driver at http://w2422.nsk.ne.jp/~inoue/.

> Another thing: on the web page, you refer to 7.2.0001,
> though the DLL claims itself to be 7.2.0002. Which is
> the truth? :)

The driver at my page is a candidate for 7.2.0002.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

Gabor here, from own address -- thanks for CC'ing. please keep on.

Well, last we discussed driver GUI problems; here is an extreme request
about the new int8 return type option:

Is it possible, and, if not a significant work, would you (Hiroshi) add
another choice, namely, int4? (argh :) ) It would be a real quick fix to our
problem to help change between the databases.

Yours,
Gabor

> -----Original Message-----
> From: SZ?CS Gabor [mailto:surrano@mailbox.hu]
> Sent: 04 June 2002 12:40
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Gabor here, from own address -- thanks for CC'ing. please keep on.
>
> Well, last we discussed driver GUI problems; here is an
> extreme request about the new int8 return type option:
>
> Is it possible, and, if not a significant work, would you
> (Hiroshi) add another choice, namely, int4? (argh :) ) It
> would be a real quick fix to our problem to help change
> between the databases.

What's wrong with int4? I don't recall hearing of any problems with them
in the last 5 years or so. If this request is to make your life easier
on your current project rather than fix an actual bug, then I would
strongly object to adding such a hack to the driver and would suggest
that you take a copy of the source and look into hacking it yourself.
The code in question is in pgtypes.c - the int8 hacks have the comment
/* Change this to SQL_BIGINT for ODBC v3 bjm 2001-01-23 */ above them
for reference.

Regards, Dave.

Dave Page wrote:

> > -----Original Message-----
> > From: SZ?CS Gabor [mailto:surrano@mailbox.hu]
> >
> > Gabor here, from own address -- thanks for CC'ing. please keep on.
> >
> > Well, last we discussed driver GUI problems; here is an
> > extreme request about the new int8 return type option:
> >
> > Is it possible, and, if not a significant work, would you
> > (Hiroshi) add another choice, namely, int4? (argh :) ) It
> > would be a real quick fix to our problem to help change
> > between the databases.
>
> What's wrong with int4? I don't recall hearing of any
> problems with them in the last 5 years or so.
> If this request is to make your life easier
> on your current project rather than fix an actual bug, then I would
> strongly object to adding such a hack to the driver and would suggest
> that you take a copy of the source and look into hacking it yourself.
> The code in question is in pgtypes.c - the int8 hacks have the comment
> /* Change this to SQL_BIGINT for ODBC v3 bjm 2001-01-23 */ above them
> for reference.

I'm not sure if the current code (returning SQL_VARCHAR)
is proper. Probably returning SQL_BIGINT is proper
but there are some(many ?) applications which couldn't
handle SQL_BIGINT properly. OTOH PostgreSQL has changed
the result type of sum(int4) from int4(pre 7.0) ->
numeric(7.1) -> int8(7.2). It's understandable to me that
there are some applications which are unable to cope with
the capricious changes.
I'm inclined to add *Int8 As int4* selection. However
note that the option is a hack and you can't cope with
int8 table columns with the option.

regards,
Hiroshi Inoue

Ahh, I see. In that case I would not be opposed to such a change. However, as Hiroshi points out in his reply, mapping
int8-> int4 may cause problems when you do get numbers bigger than 2,147,483,647 but of course, that may not apply to
yoursituation. 

Regards, Dave.

> -----Original Message-----
> From: SZUCS Gábor [mailto:surrano@mailbox.hu]
> Sent: 04 June 2002 17:31
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Dear Dave,
>
> Oh no and oh yes, you are both right and wrong. Let me explain.
>
> ----- Original Message -----
> From: "Dave Page" <dpage@vale-housing.co.uk>
> Sent: Tuesday, June 04, 2002 6:00 PM
>
>
> > Is it possible, and, if not a significant work, would you
> > (Hiroshi) add another choice, namely, int4? (argh :) ) It
> would be a
> > real quick fix to our problem to help change between the databases.
> <<<
> What's wrong with int4? I don't recall hearing of any
> problems with them
> >>>
>
> No problem with int4. Now I see that I wasn't crystal clear
> about my question. I asked if it's possible to add the driver
> another option to convert int8 to int4 (SQL_INTEGER or whatsis).
>
> <<<
> in the last 5 years or so. If this request is to make your
> life easier on your current project rather than fix an actual
> bug, then I would
> >>>
>
> Yes, it's to make our lives easier. It would be a necessary
> adjustment for us to change from PostgreSQL 7.1.3 to 7.2, or
> else the workaround would be a real pain (revisit all
> queries, server-side functions, triggers and tables). This
> could be done in time but it is time we really don't have
> much to change to 7.2. I.e, once we have 7.2 working, we'll
> have time to do the workaround and drop this excuse of an option.
>
> This is why I tried to ask Hiroshi as humbly as my English
> allows to see if it's easily done.
>
> As for the source, I'm unsure if we have the development
> tools to compile the driver, but if nobody else will do it --
> well, we'll have to do it ;)
>
> <<<
> The code in question is in pgtypes.c - the int8 hacks have the comment
> /* Change this to SQL_BIGINT for ODBC v3 bjm 2001-01-23 */
> above them for reference.
> >>>
>
> Thanks for the reference, It's really valuable.
>
> Yours,
> Gábor
> --
> There are 10 kinds of people:
> those who understand binary numbers and those who don't.
>
>

SZUCS G畸or wrote:
>
> ----- Original Message -----
> From: "Dave Page" <dpage@vale-housing.co.uk>
>
> <<<
> Ahh, I see. In that case I would not be opposed to such a change.
> However, as Hiroshi points out in his reply, mapping int8 -> int4
> may cause problems
> when you do get numbers bigger than 2,147,483,647 but of course,
> that may not apply to your situation.
> >>>
>
> Thanks for Hiroshi for the positive response, we can't wait for the new
> version ;)

Please try the snapshot dll at my page.
It would also fix the bug reported by your another mail.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 04 June 2002 01:50
> To: Laszlo Tibor; Dave Page
> Cc: pgsql-odbc@postgresql.org; surrano@mailbox.hu
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Laszlo Tibor wrote:
> >
> > Gabor again.
> >
> > > -----Original Message-----
> > > From: Dave Page
> > > Sent: Friday, May 31, 2002 9:30 AM
> >
> > > - Can we use a tabset rather than next/previous page
> buttons (which
> > > vanish when you click the defaults button!). I think it
> would make a
> > > far cleaner (and standard) interface.
>
> Maybe but I'm not good at Windows GUI programming using C
> unfortunately. I've mainly used C++(MFC) in GUI programming.

Well, it's not exactly my area, but I'll give it ago if I get a few
minutes. How up-to-date is the main CVS with your recent changes?

Regards, Dave.

Dear Dave,

Oh no and oh yes, you are both right and wrong. Let me explain.

----- Original Message -----
From: "Dave Page" <dpage@vale-housing.co.uk>
Sent: Tuesday, June 04, 2002 6:00 PM


> Is it possible, and, if not a significant work, would you
> (Hiroshi) add another choice, namely, int4? (argh :) ) It
> would be a real quick fix to our problem to help change
> between the databases.
<<<
What's wrong with int4? I don't recall hearing of any problems with them
>>>

No problem with int4. Now I see that I wasn't crystal clear about my
question. I asked if it's possible to add the driver another option to
convert int8 to int4 (SQL_INTEGER or whatsis).

<<<
in the last 5 years or so. If this request is to make your life easier
on your current project rather than fix an actual bug, then I would
>>>

Yes, it's to make our lives easier. It would be a necessary adjustment for
us to change from PostgreSQL 7.1.3 to 7.2, or else the workaround would be a
real pain (revisit all queries, server-side functions, triggers and tables).
This could be done in time but it is time we really don't have much to
change to 7.2. I.e, once we have 7.2 working, we'll have time to do the
workaround and drop this excuse of an option.

This is why I tried to ask Hiroshi as humbly as my English allows to see if
it's easily done.

As for the source, I'm unsure if we have the development tools to compile
the driver, but if nobody else will do it -- well, we'll have to do it ;)

<<<
The code in question is in pgtypes.c - the int8 hacks have the comment
/* Change this to SQL_BIGINT for ODBC v3 bjm 2001-01-23 */ above them
for reference.
>>>

Thanks for the reference, It's really valuable.

Yours,
Gábor
--
There are 10 kinds of people:
those who understand binary numbers and those who don't.

----- Original Message -----
From: "Dave Page" <dpage@vale-housing.co.uk>
To: "SZUCS Gábor" <surrano@mailbox.hu>
Cc: <pgsql-odbc@postgresql.org>; "Hiroshi Inoue" <Inoue@tpf.co.jp>
Sent: Wednesday, June 05, 2002 9:48 AM
Subject: RE: [ODBC] int8 becames string in BDE :-(

<<<
Ahh, I see. In that case I would not be opposed to such a change. However,
as Hiroshi points out in his reply, mapping int8 -> int4 may cause problems
when you do get numbers bigger than 2,147,483,647 but of course, that may
not apply to your situation.
>>>


Since our largest tables are ~100k rows and those candidate for joins are
even lesser, it's an acceptable restriction unless we join 3 tables without
where's. This is concerning count(). Other int8 results such as nextval and
currval are also out of suspicions: it is unlikely to have more than 2^31
lines in any table concerning human lifetime.

Thanks for Hiroshi for the positive response, we can't wait for the new
version ;)

G.
--
There are 10 kinds of people:
those who understand binary numbers and those who don't.

Thanks, both changes worked!

G.
--
There are 10 kinds of people:
those who understand binary numbers and those who don't.

> Please try the snapshot dll at my page.
> It would also fix the bug reported by your another mail.

Dave Page wrote:
>
> > > > - Can we use a tabset rather than next/previous page
> > buttons (which
> > > > vanish when you click the defaults button!). I think it
> > would make a
> > > > far cleaner (and standard) interface.
> >
> > Maybe but I'm not good at Windows GUI programming using C
> > unfortunately. I've mainly used C++(MFC) in GUI programming.
>
> Well, it's not exactly my area, but I'll give it ago if I get a few
> minutes. How up-to-date is the main CVS with your recent changes?

I've just committed the recent change.
Now the main cvs is up-to-date.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 06 June 2002 06:10
> To: Dave Page
> Cc: Laszlo Tibor; pgsql-odbc@postgresql.org; surrano@mailbox.hu
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Dave Page wrote:
> >
> > > > > - Can we use a tabset rather than next/previous page
> > > buttons (which
> > > > > vanish when you click the defaults button!). I think it
> > > would make a
> > > > > far cleaner (and standard) interface.
> > >
> > > Maybe but I'm not good at Windows GUI programming using C
> > > unfortunately. I've mainly used C++(MFC) in GUI programming.
> >
> > Well, it's not exactly my area, but I'll give it ago if I get a few
> > minutes. How up-to-date is the main CVS with your recent changes?
>
> I've just committed the recent change.
> Now the main cvs is up-to-date.

Hmm, I'm getting numerous build errors - the first of which is that
win_setup.h is missing! Did you forget to add it to CVS?

Regards, Dave.

Dave Page wrote:
>
> > -----Original Message-----
> > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> > Sent: 06 June 2002 06:10
> > To: Dave Page
> > Cc: Laszlo Tibor; pgsql-odbc@postgresql.org; surrano@mailbox.hu
> > Subject: Re: [ODBC] int8 becames string in BDE :-(
> >
> >
> > Dave Page wrote:
> > >
> > > > > > - Can we use a tabset rather than next/previous page
> > > > buttons (which
> > > > > > vanish when you click the defaults button!). I think it
> > > > would make a
> > > > > > far cleaner (and standard) interface.
> > > >
> > > > Maybe but I'm not good at Windows GUI programming using C
> > > > unfortunately. I've mainly used C++(MFC) in GUI programming.
> > >
> > > Well, it's not exactly my area, but I'll give it ago if I get a few
> > > minutes. How up-to-date is the main CVS with your recent changes?
> >
> > I've just committed the recent change.
> > Now the main cvs is up-to-date.
>
> Hmm, I'm getting numerous build errors - the first of which is that
> win_setup.h is missing! Did you forget to add it to CVS?

Oops I forgot to add it, sorry.
I've just added it to CVS.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 06 June 2002 10:51
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Dave Page wrote:
> >
> > Hmm, I'm getting numerous build errors - the first of which is that
> > win_setup.h is missing! Did you forget to add it to CVS?
>
> Oops I forgot to add it, sorry.
> I've just added it to CVS.
>

Thanks - that builds OK now. Is it correct that only the first dialog is
used for default settings?

Regards, Dave.

Dave Page wrote:
>
> > -----Original Message-----
> > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> > Sent: 06 June 2002 10:51
> > To: Dave Page
> > Cc: pgsql-odbc@postgresql.org
> > Subject: Re: [ODBC] int8 becames string in BDE :-(
> >
> >
> > Dave Page wrote:
> > >
> > > Hmm, I'm getting numerous build errors - the first of which is that
> > > win_setup.h is missing! Did you forget to add it to CVS?
> >
> > Oops I forgot to add it, sorry.
> > I've just added it to CVS.
> >
>
> Thanks - that builds OK now. Is it correct that only the first dialog is
> used for default settings?

Yes. The options in the first page were per driver before
7.1.0007. I'm not sure if it's valuable to allow default
settings for the second page.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 06 June 2002 11:22
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Dave Page wrote:
> >
> > > -----Original Message-----
> > > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> > > Sent: 06 June 2002 10:51
> > > To: Dave Page
> > > Cc: pgsql-odbc@postgresql.org
> > > Subject: Re: [ODBC] int8 becames string in BDE :-(
> > >
> > >
> > > Dave Page wrote:
> > > >
> > > > Hmm, I'm getting numerous build errors - the first of which is
> > > > that win_setup.h is missing! Did you forget to add it to CVS?
> > >
> > > Oops I forgot to add it, sorry.
> > > I've just added it to CVS.
> > >
> >
> > Thanks - that builds OK now. Is it correct that only the
> first dialog
> > is used for default settings?
>
> Yes. The options in the first page were per driver before
> 7.1.0007. I'm not sure if it's valuable to allow default
> settings for the second page.
>

Personnally (having installed it literally hundreds of times) I'm not
convinced that there is any real benefit in having any defaults other
than the hard coded ones. They will be about right for 90% of people,
and for the other 10% many will not use more than one or two DSNs
anyway.

In an ideal world, *I* (and I realise others may disagree) I think we
should have a simplified list of options, taking into account that some
are no longer relevant, and that the only defaults are those that are
hardcoded into the driver.

Regards, Dave.

> -----Original Message-----
> From: zuschlag2@online.de [mailto:zuschlag2@online.de]
> Sent: 06 June 2002 14:58
> To: Dave Page
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Dave Page <dpage@vale-housing.co.uk> schrieb am 06.06.2002, 12:36:21:
>
> > and for the other 10% many will not use more than one or two DSNs
> > anyway.
>
> I use 3 and more...

Actually, I have about 8 on my own machine, but I never use the defaults
- I just set them up individually.

> > In an ideal world, *I* (and I realise others may disagree)
> I think we
> > should have a simplified list of options, taking into account that
> > some are no longer relevant, and that the only defaults are
> those that
> > are hardcoded into the driver.
>
> I agree.
>
> regards
>
> Johann Zuschlag
>

Dave Page wrote:
>
> > > > Dave Page wrote:
> > > > >
> > > > > Hmm, I'm getting numerous build errors - the first of which is
> > > > > that win_setup.h is missing! Did you forget to add it to CVS?
> > > >
> > > > Oops I forgot to add it, sorry.
> > > > I've just added it to CVS.
> > > >
> > >
> > > Thanks - that builds OK now. Is it correct that only the
> > first dialog
> > > is used for default settings?
> >
> > Yes. The options in the first page were per driver before
> > 7.1.0007. I'm not sure if it's valuable to allow default
> > settings for the second page.
> >
> Personnally (having installed it literally hundreds of times) I'm not
> convinced that there is any real benefit in having any defaults other
> than the hard coded ones. They will be about right for 90% of people,
> and for the other 10% many will not use more than one or two DSNs
> anyway.

OK but as for CommLog and Mylog in default settings, they
not only mean defaults but also decide if the driver should
take the log info before connection is established.
How should we handle the options ?

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 07 June 2002 03:41
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> OK but as for CommLog and Mylog in default settings, they
> not only mean defaults but also decide if the driver should
> take the log info before connection is established.
> How should we handle the options ?
>

Hmm, good question!

Is there much reason to have the logging enabled during setup or before
the DSN is known? I don't recall anyone reporting problems during these
periods.

The only other example I can think of where this might be an issue is in
a DSNless connection, though I think that if an application wants to
open a DSNless connection, then it's up to that application to be aware
of the driver it's using. pgAdmin II does this - it specifies all it's
required options in the connection string, including mylog/commlog if
required - doing it that way *significantly* reduced the problem reports
I got from people with misconfigured DSNs (and those that left the
prompt at the default and attempted to use pgAdmin I to connect to
'dBase Files'!!).

Perhaps we should remove them from the dialog for simplicities sake, but
leave the registry options so that in the unlikely event that anyone
does need logging during setup or startup they can enable it through
regedit.

What do you think?

Regards, Dave.

Dave Page wrote:
>
> > -----Original Message-----
> > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> >
> > OK but as for CommLog and Mylog in default settings, they
> > not only mean defaults but also decide if the driver should
> > take the log info before connection is established.
> > How should we handle the options ?
> >
>
> Hmm, good question!
>
> Is there much reason to have the logging enabled during setup or before
> the DSN is known? I don't recall anyone reporting problems during these
> periods.

The following is a Mylog using MS Access. You can't see the log
unless you check the Default Mylog option.

EN_add_connection: self = 162268416, conn = 162231696
       added at i =0, conn->henv = 162268416, conns[i]->henv = 162268416
[SQLGetInfo]PGAPI_GetInfo: entering...fInfoType=77
PGAPI_GetInfo: p='02.50', len=0, value=0, cbMax=12
[SQLSetConnectionOption]PGAPI_SetConnectOption: entering fOption = 103
vParam = 20
[SQLGetConnectOption]PGAPI_GetConnectOption: entering...
CONN ERROR: func=PGAPI_GetConnectOption, desc='fOption=30002',
errnum=205, errmsg='Unknown connect option (Get)'
[SQLSetConnectionOption]PGAPI_SetConnectOption: entering fOption = 30002
vParam = 149101976
Microsoft Jet !!!!
[SQLDriverConnect]PGAPI_DriverConnect: entering...
**** PGAPI_DriverConnect: fDriverCompletion=1, connStrIn='DSN=tako;'
our_connect_string = 'DSN=tako;'
attribute = 'DSN', value = 'tako'
copyAttributes:
DSN='tako',server='',dbase='',user='',passwd='',port='',onlyread='',protocol='',conn_settings='',disallow_premature=-1)
globals.extra_systable_prefixes = 'dd_;'
our_connect_string = 'DSN=tako;'
attribute = 'DSN', value = 'tako'
CopyCommonAttributes:
A7=100;A8=4096;A9=0;B0=254;B1=8191;B2=1;B3=1;B4=1;B5=1;B6=0;B7=0;B8=0;B9=0;C0=0;C1=0;C2=dd_;

You can see the subsequent log info if you check the Mylog
option per DSN.

CC_connect: entering...

We can't see e.g. connect string if we turn off the
Default Mylog option.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 10 June 2002 02:07
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> We can't see e.g. connect string if we turn off the
> Default Mylog option.

OK, so we leave those as they are. They are not so much 'Default', as
'Global' settings anyway, and removing all bar them will still make
things a lot more simple.

Regards, Dave.

Dave Page wrote:
>
> > -----Original Message-----
> > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> >
> > We can't see e.g. connect string if we turn off the
> > Default Mylog option.
>
> OK, so we leave those as they are. They are not so much 'Default', as
> 'Global' settings anyway, and removing all bar them will still make
> things a lot more simple.

OK I changed *Driver*  --> *Global* and the *Global* has
only 2 entries(Commlog and Mylog).
Please try the snapshot dll at my page.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/

> -----Original Message-----
> From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> Sent: 11 June 2002 04:59
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] int8 becames string in BDE :-(
>
>
> Dave Page wrote:
> >
> > > -----Original Message-----
> > > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> > >
> > > We can't see e.g. connect string if we turn off the
> > > Default Mylog option.
> >
> > OK, so we leave those as they are. They are not so much
> 'Default', as
> > 'Global' settings anyway, and removing all bar them will still make
> > things a lot more simple.
>
> OK I changed *Driver*  --> *Global* and the *Global* has
> only 2 entries(Commlog and Mylog).
> Please try the snapshot dll at my page.

Looks good. There are some minor UI issues though (badly sized labels,
descriptions that could be improved etc - mainly longstanding issues) -
if you can commit your changes, I'll tidy it up and send you a patch if
you like.

Regards, Dave.

Dave Page wrote:
>
> > -----Original Message-----
> > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> >
> > Dave Page wrote:
> > >
> > > > -----Original Message-----
> > > > From: Hiroshi Inoue [mailto:Inoue@tpf.co.jp]
> > > >
> > > > We can't see e.g. connect string if we turn off the
> > > > Default Mylog option.
> > >
> > > OK, so we leave those as they are. They are not so much
> > 'Default', as
> > > 'Global' settings anyway, and removing all bar them will still make
> > > things a lot more simple.
> >
> > OK I changed *Driver*  --> *Global* and the *Global* has
> > only 2 entries(Commlog and Mylog).
> > Please try the snapshot dll at my page.
>
> Looks good. There are some minor UI issues though (badly sized labels,
> descriptions that could be improved etc - mainly longstanding issues) -
> if you can commit your changes, I'll tidy it up and send you a patch
> if you like.

I've just committed the change to cvs.
Please improve the UI.

regards,
Hiroshi Inoue
    http://w2422.nsk.ne.jp/~inoue/