Thread: .NET driver
I used NPGSQL .NET driver to connect PGSQL 8.2.4 database to <a href="http://VB.NET">VB.NET</a>. As stated on NPGSQL page,it doesn't seem to provide seamless integration and performance with .NET. Instead when I used ODBC, the performancewas comparatively better. What's the reason? When can we expect .NET driver that provides seamless integration.<br />
Ü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 Fedoraand 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
> ------- Original Message ------- > From: "Rohit Khare" <rpk.general@gmail.com> > To: "Dave Page" <dpage@postgresql.org> > Sent: 04/08/07, 12:58:25 > Subject: Re: [HACKERS] .NET driver > > Seeing the history of PostgreSQL development, following features are > expected in pgAdmin: I don't see what any of these have to do with PostgreSQL history but... > (1) Facility to insert a column in between other columns during table > design. PostgreSQL doesn't allow this post-creation, though the new table dialog that's expected in the next dev cycle will allowit pre-creation. > (2) Facility to view relationship diagram. E-R diagramming is being developed as a Summer of Code project. > (3) Facility to view table performance level graphically. What does that mean? You can view the table details graphically as part of a query plan, and we're looking at plotting datadistribution histograms, but I'm not sure that either can be defined as "performance level" > (4) More documented interface. Example: while creating columns, few boxes > are disabled. There is no information on-screen on how to enable them. You usually cannot. They will be relevant to older (or newer) versions of the server. > (5) Facility to print table details (Name,DataType,Size,Constraint etc.) We have reports that you can print. > (6) Database Statistics (health, index details, log monitoring, > Enable/Disable Backup/Recovery Options, Fine Tuning etc.) Afaics, we have all of those (and have enhanced many for 1.8). Regards, Dave