Hacker News Reader

Comment by polskibus | Hacker News Reader

Still no production-ready ODBC in .NET Core? How is one supposed to work with database engines in a standard way? Java is miles ahead by just sticking to JDBC.

Microsoft first moved off ODBC towards OLE DB only to ditch it some years later.

Working with data and being able to connect to a plethora of data sources is essential to a platform success. .NET Core won't be treated as a serious cross-platform toolkit if it won't offer a reliable, interoperable interface.

View on HN

.NET Core didn't have DataSet/Table/View until v2.0. I'm still boggled by the idea that they think those are legacy (https://github.com/dotnet/corefx/issues/1039#issuecomment-77...) and that everybody will just use entity framework for everything.

I wonder how did they implement Power BI? Surely by implementing it, they must've realized that a robust set of fairly low level interoperable APIs is essential for working with data. EF is often too slow, that's why Dapper et al are used instead.

Are you concerned about the overhead of EF? Porting old code? If you want db-specific features, you could always call a stored proc.

EF code first is very pleasant to develop with, and when starting a new project in .NET Core, I'd always prefer that.

Will every database vendor provide a driver for EF for both windows and Linux? Is EF a real standard like odbc and jdbc?

I'm mainly involved in data integration. I don't have access to the data model that the applications I integrate use. I don't have access to the application source code; I have access to the data store. I don't need to extract an object, manipulate it, and then put it back where I got it. I typically need to take a set of all objects, transform them (typically with VIEWs), serialize them, and import them into another system that almost certainly don't represent the underlying objects in the same manner. No matter what, though, I usually don't get to have access to whatever ORM the application was created with. We do not have access to source code. Sometimes it's a matter of creating CSV data files for scheduled import, but sometimes it's me doing the actual direct manipulation of the data systems.

Some of them do have APIs, but since I already need to understand the data store to do reporting with all the third party reporting software we have, learning the API is an additional task on top of already needing to learn the data store. Come to think of it, I don't even know how you would even write third party reporting software without something basic like a DataTable. Furthermore, most systems are complex enough that whatever the developers envisioned they should be used for, however the developers thought we would configure our systems, and whatever they envisioned their customers would require of them is almost certainly incorrect, inadequate, or both.

Finally, some of my processes do use stored procedures, but most of them use table-valued parameters in order to control how the data are submitted. As far as I'm aware, EF doesn't have any support for TVPs.

Almost nothing I write is written in Visual Studio. Not that I can't, but it's not particularly useful to do so. I don't have nuget or chocolatey installed on any of the systems I work with. I do use SSIS when I can, but that's usually out of BIDS or SSDT, not VS. Others use PowerShell scripts with System.Data and whatever .Net provider I need for that DB.

Looks like you have lots of options. And you could use the SqlClient library directly.

https://blogs.msdn.microsoft.com/dotnet/2016/11/09/net-core-...

Also, regular .NET Framework will be supported for a long time.

System.Data.Odbc? https://www.nuget.org/packages/System.Data.Odbc/

It's been in preview for ages. I hope with .NC 2.1 it will be production ready and well tested on all platforms.

Reply on news.ycombinator.com