From: Sbragion Denis <infotecn@tin.it>
To: Byron Nikolaidis <byronn@insightdist.com>
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] Access'97 and ODBC
Date: Thu, 30 Apr 1998 08:38:36 +0200
Message-ID: <3.0.5.32.19980430083836.007f3330@MBox.InfoTecna.com> (raw)
In-Reply-To: <35472BAD.2BB5C74E@insightdist.com>
References: <Pine.LNX.3.96.980427141308.1975A-100000@proxy.bazzanese.com>
<3545ECD6.5615904D@sid.trust.ee>
<3.0.5.32.19980429090507.007f5ea0@MBox.InfoTecna.com>
Hello,
At 09.31 29/04/98 -0400, Byron Nikolaidis wrote:
>I'm not sure why VisData still isn't able to show the index list. First
of all,
>I dont know what "VisData" is anyway! Perhaps you could use the odbc tracing
VisData is a small tool provided with visual basic 5.0. It provides a
graphical representation of all the feature of any database that could be
opened through visual basic, including ODBC databases. It is quite an hard
test for any ODBC driver because it tries to show *almost anything* that
could be retrieved through an ODBC driver, not only data. Most ODBC
drivers, even some "famous" one, fail with VisData and still can perfectly
be used in normal applications.
>feature (through the 32 bit odbc administrator) and send the "sql.log" to me.
>Make sure it is empty before you begin your session. This will really slow
>things down by the way.
I'll do it ASAP, and I'll provide also the exact sequence of operation
performed to show the problems. Anyway the problem showed with VisData has
no importance at all, at least using Visual Basic and Access. ASAP I'll
also perform some test using Power Builder, wich uses the ODBC in a
different way than VB.
>As for performance, the backend affects that equation greatly. You should
see
>what happens in Access when you are using unique indexes. Even with one
keypart,
>Access generates that infamous query we have been talking about (with all the
>ANDs and ORs), which really slows things down.
I know. Anyway I was not using Access but a small test program I wrote
myself. This program perform random operations (insert, update, select and
delete) through recordset opened on simple tables, so it doesn't suffer
the Access "feature" of creating too complex queries. I know this is not a
deep test, anyway it is the sort of operations 90% of VB code perform on
databases. I think first we should obtain a functioning ODBC driver, i.e.
you should continue on the way you are going now. After this we could take
care of performances. Doing things in reverse order usually produce "very
fast non functioning code", which is not usefull at all ;)
Bye !
Dr. Sbragion Denis
InfoTecna
Tel, Fax: +39 39 2324054
URL: http://space.tin.it/internet/dsbragio
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: infotecn@tin.it, byronn@insightdist.com
Subject: Re: [INTERFACES] Access'97 and ODBC
In-Reply-To: <3.0.5.32.19980430083836.007f3330@MBox.InfoTecna.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox