Date: Thu, 08 Jun 2000 10:05:23 -0400
From: Mihai Gheorghiu <tanhq@bigplanet.com>
Subject: Re: Win ODBC drivers for Postgres
To: pgsql-interfaces@postgresql.org
Cc: pgsql-general@postgresql.bigplanet.com
Message-id: <002f01bfd152$b3247e60$2716113f@new6>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit

Ladies and gentlemen,
Please accept my sincere apologies.
I was just as frustrated as you were when reading that person's Memo. He
tried to take advantage of what the French say, "Les absents ont toujours
tort." - Absents are always wrong.
Given my very limited experience with PostgreSQL, I needed arguments to
support my option.
Now the jury is out. I hope they will vote for Open Source, at least for
financial reasons.
Actually the document tried to justify a network architecture that required
transactional replication (2way :-(  MS claims it is built in their SQL7.
If this will be a requirement, what is the timeframe for having that
implemented in PostgreSQL? It is my understanding this can be done now too,
only by programming.

Best regards,

Mihai


>Hello,
>
>At 10.36 07/06/00 -0400, you wrote:
>>Quote:
>>[ODBC public domain drivers] are immature, inefficient and are network
>>bandwidth hogs. The public domain drivers don't support connection caching
>>which reuses an existing database connection for same queries to reduce
the
>>query result time.
>
>well, don't know about the internals of the PostODBC driver, anyway I have
>performed many tests on it. The latest version of the driver coupled with
>the latest version of PostgreSQL with my tests was about 2 times faster
>than MS SQL Server 6.5 with its own ODBC Driver, especially when more than
>one concurrent connection was used. And in my experience (real experience,
>not benchmarks) most commercial databases are slower than MS SQL Server and
>have ODBC drivers that are almost useless because of bugs, unimplemented
>features and many other quirks. I''m just working with Centura SQL Base
>(version 6.1.something) with its own ODBC. It's just a pain. It doesn't
>report indices and primary keys so Visual Basic with DAO refuse to perform
>any write operation with it. I have to build complex SQL statements to do
>any change to the data contained in the database. Every now and then it
>refuses to connect to the database with no apparent reason, and so on.
>         I simply completely disagree with the above statement. There's
>nothing slower than something that simply doesn't work at all, and many
>commercial databases simply doesn't work, who cares if they are faster when
>they work?
>
>Bye!
>--
> Denis Sbragion
> InfoTecna
> Tel, Fax: +39 039 2324054
> URL: http://www.infotecna.it
>