Thread: From ODBC to .NET provider
Has anyone moved from the ODBC driver to a native .NET provider? Any recommendations on which Postgres .NET provider to go with? There are a couple commercial versions and the open soruce one.... Jon
On 21 Jul 2004 at 12:53, Jon Asher wrote:
> Has anyone moved from the ODBC driver to a native .NET provider? Any
> recommendations on which Postgres .NET provider to go with? There are a
> couple commercial versions and the open soruce one....
>
> Jon
>
Yes, I've done some work with .NET (C#) and PostgreSQL. I started using the ODBC driver which works pretty well. Just one bug with calling stored procedures with int2 parameters. The driver doesn't typecast the int2 parameters and so can't find the function. Otherwise no real problems.
I moved to using Npgsql native driver for mainly performance reasons. Unfortunately I have to maintain a codebase that supports both postgres and MS SQL Server. To minimise the code changes I have gone back to ODBC.
Npgsql seems to perform very well and I never had any trouble using it. I tend to keep my ADO.NET stuff fairly simple though. Connections, Commands (both text and stored procedures), Datareaders. I don't use datasets so I can't tell you about this area and Npgsql.
I have tried the PostgreSQL Direct driver from CoreLabs as I wanted to use their Unidriver to maintain compatibility with SQLServer, but it is very buggy at the moment.
I would say that if you need to go native, then use the open source one (Npgsql)
Cheers,
Gary.
That's good to know re the Corelabs driver which I'd been looking at also. I see that they released a 1.8 build in Jun 04- do you remember which build you were testing? It looks like Npgsql is the way to go anyway. Jon ----- Original Message ----- > On 21 Jul 2004 at 12:53, Jon Asher wrote: > >> Has anyone moved from the ODBC driver to a native .NET provider? Any >> recommendations on which Postgres .NET provider to go with? There are a >> couple commercial versions and the open soruce one.... >> >> Jon >> > Yes, I've done some work with .NET (C#) and PostgreSQL. I started using > the ODBC > driver which works pretty well. Just one bug with calling stored > procedures with int2 > parameters. The driver doesn't typecast the int2 parameters and so can't > find the > function. Otherwise no real problems. > > I moved to using Npgsql native driver for mainly performance reasons. > Unfortunately I > have to maintain a codebase that supports both postgres and MS SQL Server. > To > minimise the code changes I have gone back to ODBC. > > Npgsql seems to perform very well and I never had any trouble using it. I > tend to keep > my ADO.NET stuff fairly simple though. Connections, Commands (both text > and stored > procedures), Datareaders. I don't use datasets so I can't tell you about > this area and > Npgsql. > > I have tried the PostgreSQL Direct driver from CoreLabs as I wanted to use > their > Unidriver to maintain compatibility with SQLServer, but it is very buggy > at the moment. > > I would say that if you need to go native, then use the open source one > (Npgsql) > > Cheers, > Gary. > >
On 21 Jul 2004 at 15:05, Jon Asher wrote: > That's good to know re the Corelabs driver which I'd been looking at also. > I see that they released a 1.8 build in Jun 04- do you remember which > build you were testing? Yes, that is the version I finally tested. Better then the previous one, but just trying to set the Command.CommandTimeout value resulted in very strange behaviour. Not very well tested I think! Reported the bug, but they didn't seem too interested. The UniDriver was all over the place. Couldn't get CommandType.StoredProcedure to work at all with any combination of parameter positions/types/names etc. At least the trial version is free for as long a you like. If you have any better luck than me, please let me know. Cheers, Gary.