Dan Freeman
Programmer
Remember that big push to use OLE-DB instead of ODBC?
Yeah, never mind.
Yeah, never mind.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Microsoft Aligning with ODBC
- Thread starter Dan Freeman
- Start date
- Status
Olaf Doschke
Programmer
MS did already superseeded LINQ, kind of, via Entity Framework. But those are different things, really.
And so is LINQ compared to OLEDB vs ODBC. LINQ rather compares to SQL, it's a query language, it doesn't depend on OLEDB directly. If you have in mind LINQ uses ADO.NET, ADO.NET uses OLEDB and that connects to the database, you're not wrong, but ADO.NET can also adress ODBC.
The question in regard of VFP is, if MS will make an ODBC driver for VFP9 DBFs. It's unlikely, I think, as the product is deprecated, it will just push VFP one more step into discontiuation, so to say, as the latest official VFP driver is OLEDB only.
MS has stepped away from what other DBMS vendors did. They refused to go that route. The same goes for LINQ. OLEDB wasn't picked up by database vendors and OS vendors (Linux community, Apple), and LINQ was even less a technology that was also supported by other DB vendors.
And as the developers went more and more web 2.0, AJAX, HTML5, they also moved more to PHP or JAVA then towards ASP.NET
MS has to step back there to ODBC to stay with the main movements.
There still is OLEDB for NON DBMS. Quoted from
...The ability to make non-DBMS data sources accessible to database applications. ... Examples of non-DBMS data sources include information in file systems, e-mail, spreadsheets, and project management tools.
Bye, Olaf.
And so is LINQ compared to OLEDB vs ODBC. LINQ rather compares to SQL, it's a query language, it doesn't depend on OLEDB directly. If you have in mind LINQ uses ADO.NET, ADO.NET uses OLEDB and that connects to the database, you're not wrong, but ADO.NET can also adress ODBC.
The question in regard of VFP is, if MS will make an ODBC driver for VFP9 DBFs. It's unlikely, I think, as the product is deprecated, it will just push VFP one more step into discontiuation, so to say, as the latest official VFP driver is OLEDB only.
MS has stepped away from what other DBMS vendors did. They refused to go that route. The same goes for LINQ. OLEDB wasn't picked up by database vendors and OS vendors (Linux community, Apple), and LINQ was even less a technology that was also supported by other DB vendors.
And as the developers went more and more web 2.0, AJAX, HTML5, they also moved more to PHP or JAVA then towards ASP.NET
MS has to step back there to ODBC to stay with the main movements.
There still is OLEDB for NON DBMS. Quoted from
...The ability to make non-DBMS data sources accessible to database applications. ... Examples of non-DBMS data sources include information in file systems, e-mail, spreadsheets, and project management tools.
Bye, Olaf.
Mike Lewis
Programmer
Is this blog post some sort of a joke?
As I was reading it, I twice had to check the date: once to make sure it wasn't 1st April, and then to check it wasn't 1999.
What's next? Will Microsoft "align" with Visual FoxPro?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
As I was reading it, I twice had to check the date: once to make sure it wasn't 1st April, and then to check it wasn't 1999.
What's next? Will Microsoft "align" with Visual FoxPro?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips, training, consultancy
Olaf Doschke
Programmer
Well,
while it's a step backward, nobody else but MS did move that step, OLE/COM/DCOM itself is a windows only feature. And from the point of view of .NET OLE wrappers to Assemblies are a leftover into the OLE world, which might be the next candidate to be deprecated. I wouldn't mind to get a more modern interoperability basis than OLE/COM/DCOM is.
From the perspective of Foxpro as a database client using ODBC for SQL Passthrough and Remote Views, the move back to ODBC and away from OLEDB actually is not bad news.
If MS would have decided against ODBC, that would leave foxpro developers with less remote database access possibilities.
We already have an VFP9 ODBC driver, the one of Sybase for Advantage Database. It only has limited support for the rest of the language besides SQL, it lacks stored procedures support and all but very few functions like LEN() or TRIM() you might be using in index expressions or SQL queries.
Bye, Olaf.
while it's a step backward, nobody else but MS did move that step, OLE/COM/DCOM itself is a windows only feature. And from the point of view of .NET OLE wrappers to Assemblies are a leftover into the OLE world, which might be the next candidate to be deprecated. I wouldn't mind to get a more modern interoperability basis than OLE/COM/DCOM is.
From the perspective of Foxpro as a database client using ODBC for SQL Passthrough and Remote Views, the move back to ODBC and away from OLEDB actually is not bad news.
If MS would have decided against ODBC, that would leave foxpro developers with less remote database access possibilities.
We already have an VFP9 ODBC driver, the one of Sybase for Advantage Database. It only has limited support for the rest of the language besides SQL, it lacks stored procedures support and all but very few functions like LEN() or TRIM() you might be using in index expressions or SQL queries.
Bye, Olaf.
Olaf Doschke
Programmer
I said: "while it's a step backward, nobody else but MS did move that step"
I meant to say: "while it's a step backward, nobody else but MS did move the step forward to OLEDB."
Bye, Olaf.
I meant to say: "while it's a step backward, nobody else but MS did move the step forward to OLEDB."
Bye, Olaf.
Dan,
Remember New Coke? Yeah, never mind.
Remember Pontiac? Yeah, never mind.
Remember Mercury? Yeah, never mind.
Remember when IBM made PCs? Yeah, never mind.
Microsoft has long been on a push to reduce COM and more recently to embrace standards. This announcement should not be a surprise.
Craig Berntson
MCSD, Visual C# MVP,
Remember New Coke? Yeah, never mind.
Remember Pontiac? Yeah, never mind.
Remember Mercury? Yeah, never mind.
Remember when IBM made PCs? Yeah, never mind.
Microsoft has long been on a push to reduce COM and more recently to embrace standards. This announcement should not be a surprise.
Craig Berntson
MCSD, Visual C# MVP,
Olaf Doschke
Programmer
Hi Craig,
yup, we never had New Coke (or Coke Classic) here in germany. As it was and is the brand #1 and not Pepsi, the Coca Cola Company never had the urge to introduce it here.
In that respect you can also say OLEDB simply was not a step forward, but a step in the wrong direction.
It's still a bit of a surprise. Now that it has been available quite some time, it's a rather late move, to revert from it. MS could also simply keep ignoring the fact nobody follows that route.
If there will be no other database access technology starting soon, that step away from OLEDB will never lead to any newer approach.
The question is: Do we need a different approach than ODBC? I'd not say no.
Bye, Olaf.
yup, we never had New Coke (or Coke Classic) here in germany. As it was and is the brand #1 and not Pepsi, the Coca Cola Company never had the urge to introduce it here.
In that respect you can also say OLEDB simply was not a step forward, but a step in the wrong direction.
It's still a bit of a surprise. Now that it has been available quite some time, it's a rather late move, to revert from it. MS could also simply keep ignoring the fact nobody follows that route.
If there will be no other database access technology starting soon, that step away from OLEDB will never lead to any newer approach.
The question is: Do we need a different approach than ODBC? I'd not say no.
Bye, Olaf.
- Status
Similar threads
