.NET driver

Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:

I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and performance with .NET. Instead when I used ODBC, the
performance was comparatively better. What's the reason? When can we
expect .NET driver that provides seamless integration.

What kind of "seamless integration" are you looking for ?

Which is more important to you "seamless integration" or performance ?

--------------
Hannu

On 8/2/07, Hannu Krosing <hannu@skype.net> wrote:

Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:

I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and performance with .NET. Instead when I used ODBC, the
performance was comparatively better. What's the reason? When can we
expect .NET driver that provides seamless integration.

What kind of "seamless integration" are you looking for ?

The .net data provider is not as good when working with typed datasets
in terms of support from the ide. Normally for other providers the
IDE does everything for you, writing update statements and such in a
ORM fashion. This is kind of a pain for some of the report designers
and other things that want to work with a typed set. It's possible to
work around this, it's just a pain, and changes with each release of
visual studio. Also, the connection pooling portions are buggy
(google LOG: incomplete startup packet).

The ODBC driver works pretty good actually. I can't speak about the
performance though.

merlin

Merlin Moncure wrote:

On 8/2/07, Hannu Krosing <hannu@skype.net> wrote:

�hel kenal p�eval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:

I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and performance with .NET. Instead when I used ODBC, the
performance was comparatively better. What's the reason? When can we
expect .NET driver that provides seamless integration.

What kind of "seamless integration" are you looking for ?

The .net data provider is not as good when working with typed datasets
in terms of support from the ide. Normally for other providers the
IDE does everything for you, writing update statements and such in a
ORM fashion. This is kind of a pain for some of the report designers
and other things that want to work with a typed set. It's possible to
work around this, it's just a pain, and changes with each release of
visual studio. Also, the connection pooling portions are buggy
(google LOG: incomplete startup packet).

The ODBC driver works pretty good actually. I can't speak about the
performance though.

merlin

I have an experience with writing ODBC driver for PostgreSQL
(https://projects.commandprompt.com/public/odbcng/). I would be happy to
help community to improve .NET data provider.

Andrei.

On Thursday 02 August 2007 08:57, Andrei Kovalevski wrote:

Merlin Moncure wrote:

On 8/2/07, Hannu Krosing <hannu@skype.net> wrote:

Ühel kenal päeval, N, 2007-08-02 kell 11:24, kirjutas Rohit Khare:

I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to VB.NET.
As stated on NPGSQL page, it doesn't seem to provide seamless
integration and performance with .NET. Instead when I used ODBC, the
performance was comparatively better. What's the reason? When can we
expect .NET driver that provides seamless integration.

What kind of "seamless integration" are you looking for ?

The .net data provider is not as good when working with typed datasets
in terms of support from the ide. Normally for other providers the
IDE does everything for you, writing update statements and such in a
ORM fashion. This is kind of a pain for some of the report designers
and other things that want to work with a typed set. It's possible to
work around this, it's just a pain, and changes with each release of
visual studio. Also, the connection pooling portions are buggy
(google LOG: incomplete startup packet).

The ODBC driver works pretty good actually. I can't speak about the
performance though.

merlin

I have an experience with writing ODBC driver for PostgreSQL
(https://projects.commandprompt.com/public/odbcng/). I would be happy to
help community to improve .NET data provider.

That would be nice. Of course none of this seems relevant to hackers, so I'd
ask those interested to check out the .net project page at
http://pgfoundry.org/projects/npgsql/

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

Andrei Kovalevski schrieb:

I have an experience with writing ODBC driver for PostgreSQL
(https://projects.commandprompt.com/public/odbcng/). I would be happy
to help community to improve .NET data provider.

Please join the Npgsql Project at http://pgfoundry.org/projects/npgsql

Francisco Figueiredo Jr. (fxjrlists[at]yahoo[dot]com[dot]br) will be
happy about some new support.

I once did some initial VS.Net 2002/3 integration but ran out of time
half the way.
It ist quite a bit of a pain as Microsoft has marked some important
classes as sealed so you will see yourself reimplementing some wheels
they already have implemented.
Plus - as Merlin stated before - VS.Net/ADO.Net is a somewhat moving
target for data provider implementations.

Brar

Robert Treat schrieb:

That would be nice. Of course none of this seems relevant to hackers, so I'd

Your'e right - of course.

But sometimes I wish 'hackers' would care a little more about their
interfaces as the best backend can't be good without good interfaces and
some of the PostgreSQL-interfaces don't reach the standard they are
reaching for other databases.
As a windows-user I still can't drag and drop a Dataset in VS.Net with
Npgsql and I still have to build a single-threaded perl if i want to use
DBD::Pg (I know about DBD::PgPP).

I'm really happy with the backend right now and I could perhaps convince
the decision makers at my job to use my personal favorite (in addition
to MSSQL) - but not as long as the interface doesn't look like the one
they are used to.

If C# will not go above 5-10% in this
http://www.postgresql.org/community/survey.13 statistic, PostgreSQL will
not be able to cover all the markets it could.
See:
http://radar.oreilly.com/archives/2006/08/programming_language_trends_1.html

As I know that this is is off-topic here I'm not going to discuss this
any further on this list but I'll respond to personal mails or follow an
invitation to 'advocacy' (to which I'm not yet subscribed) or any other
convenient list.

Regards,

Brar

Brar Piening wrote:

Robert Treat schrieb:

That would be nice. Of course none of this seems relevant to hackers,
so I'd

Your'e right - of course.

But sometimes I wish 'hackers' would care a little more about their
interfaces as the best backend can't be good without good interfaces
and some of the PostgreSQL-interfaces don't reach the standard they
are reaching for other databases.
As a windows-user I still can't drag and drop a Dataset in VS.Net with
Npgsql and I still have to build a single-threaded perl if i want to
use DBD::Pg (I know about DBD::PgPP).

This latter is simply not true.

ActiveState Perl is threaded and DBD::Pg works just fine with it. In
fact, you don't need to build your own - just get the one from pgfoundry:

point your ppm at: http://dbdpgppm.projects.postgresql.org//DBD-Pg-5.8.ppd

cheers

andrew

On Thu, 02 Aug 2007 18:19:36 -0400
Andrew Dunstan <andrew@dunslane.net> wrote:

Brar Piening wrote:

Robert Treat schrieb:

That would be nice. Of course none of this seems relevant to
hackers, so I'd

Your'e right - of course.

But sometimes I wish 'hackers' would care a little more about their
interfaces as the best backend can't be good without good
interfaces and some of the PostgreSQL-interfaces don't reach the
standard they are reaching for other databases.
As a windows-user I still can't drag and drop a Dataset in VS.Net
with Npgsql and I still have to build a single-threaded perl if i
want to use DBD::Pg (I know about DBD::PgPP).

This latter is simply not true.

ActiveState Perl is threaded and DBD::Pg works just fine with it. In
fact, you don't need to build your own - just get the one from
pgfoundry:

And I've been using a threaded Perl on Linux/BSD systems for
years. In fact, unless someone recompiles Perl every Fedora
and RHEL system out there using Perl/DBI is doing it with a
Perl compiled with thread support.

-------------------------------------------------------
Frank Wiles, Revolution Systems, LLC.
Personal : frank@wiles.org http://www.wiles.org
Work : frank@revsys.com http://www.revsys.com

Frank Wiles wrote:

ActiveState Perl is threaded and DBD::Pg works just fine with it. In
fact, you don't need to build your own - just get the one from
pgfoundry:

And I've been using a threaded Perl on Linux/BSD systems for
years. In fact, unless someone recompiles Perl every Fedora
and RHEL system out there using Perl/DBI is doing it with a
Perl compiled with thread support.

Yes, but the OP was specifically complaining about Windows support.

cheers

andrew