The problem you describe is one of the computer industry and not just Microsoft. Some would consider it arrogance to blame Microsoft for things that are due to an immature industry. If you can do so much better than them, then you make a product and get 90% of the desktops.
1. Why does every OS have a firewall with different rulesets? Even Linux changed "standards" from 2.2 to 2.4. 2. Why does every Unix and even every Linux distribution have TCP/IP configuration stored in a different file? System startup scripts same problem. Redhat not the same as Suse, OpenBSD vs FreeBSD, etc., etc. By the _it is negative_ logic of "XYZ company changes standards" - how does "no standard at all" compare? 3. Why did OS/2 break video and network drivers between release 1.3 and 2.0? 4. Why won't my Linux drivers for a PCI sound blaster work on the Intel Itanium when they work on my Intel Pentium 4 Xeon? I could go on and on. Can we stop with the BS here? Microsoft has 90% of the clients. And the "database driver" is what you put on the client. The dotNet driver standard is over 4 years old (it as in beta for at least 2 years before being released) and even sluggish anti-Microsoft companies like Oracle have already released their dotNet driver. Porting ODBC to dotNet I would consider nearly impossible :) The XServer SAPDB protocol is poorly documented at best, it isn't like there is a driver SDK. A dotNet driver is only going to help SAPDB / MaxDB. If you want to hurt Microsoft, hit them where it hurts - on an expensive product like SQL Server ($40,000 for a 2cpu license that supports more than 1.7GB of RAM and unlimited users required for a web server). I'm sorry if I'm the first to break the news... but Linux hasn't taken over the world. Reports of Windows death is a little premature. Every other DBMS out there has a driver. The plate is vacant. Any Java programmers willing to step up to do a clean C# reverse engineering of the SAPDB JDBC driver? Is $5000 in funding really of no interest? That is the cheapest I can replace SAPDB with a unlimited user license required for a web site. Sybase,Oracle,Microsoft all want that (or more) per processor. If you are scared of the Microsoft side, there are open source c# drivers for MySQL / PostgreSQL to use as a sample code structure. Stephen -----Original Message----- From: Noah J SILVA [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 12:59 PM To: Stephen Gutknecht (SAPDB) Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: SAPDB not competitive due to neglect of Win32 drivers Stephen, I realize you would like ADO, OleDB, or .NET drivers, but look at the history of Microsoft. They come up with a "Standard", and then change it very often. Everybody else in the industry has to keep up, and why? Did ODBC stop working? no. What about all the incompatible MAPI standards? The 35 different function calls to launch another program? Obviously I could go on. ODBC works, and there are bridges from ODBC to every other database technology (like DBX, for example). If the bridge doesn't work, then it's broken, and should be fixed. ODBC is also the closest to a standard that Microsoft supports, so it is probably the best one to use. Of course it might be more convenient if there were ADO or .NET drivers for SAPDB, but it would be taking time that could be spent improving SAPDB in other ways. I also an concerned about the new licensing model, but we are prepared to maintain our own fork of SAPDB. I should note that SAPDB also isn't directly supported by Gnome-DB (but since ODBC is...). Thank you, Noah Silva IS&T - Programmer Analyst (215) 419 - 7916 "Stephen Gutknecht (SAPDB)" <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 08/08/2003 03:35 PM To: [EMAIL PROTECTED] cc: Subject: SAPDB not comptetive due to neglect of Win32 drivers Thomas, It is more fundamental than our personal stability problems with ODBC driver. OLEDB has been the newer standard for Windows drivers for many years and SAP never bothered. Now dotNet is over 18 months shipping and still no interest in a driver. It isn't just my personal interest, I fear that SAPDB / MaxDB seems to continue to ignore a huge target - taking on Windows Server users. SAPDB has equal kernel support for Windows and Unix platforms. SAPDB could be an ideal product for people migrating from Oracle or SQL Server but still wanting to stay on Windows Server for the OS (it is not uncommon to have a .... MaxDB. Alas, they have neglected the Win32 server platform (which they are addressing a native port (not cygwin) in 7.4). SAPDB is ahead of PostgreSQL in the native win32 port. But SAPDB is behind PostgreSQL in FreeBSD/*BSD support + _way behind_ in driver support. PostgreSQL: ODBC + OleDB + dotNet drivers Firebird & Interbase: ODBC + OleDB + dotNet drivers MySQL: ODBC + OleDB + dotNet drivers (multiple choices for dotNet drivers) SAPDB: ODBC only Thomas: You acknowledged on Tue 9/24/2002 the socket problems in the SAPDB Win32 ODBC driver under high concurrency. You DID reproduce that problem. Stephen Gutknecht -----Original Message----- From: Koetter, Thomas Theodor [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 1:13 AM To: 'Stephen Gutknecht (SAPDB)'; [EMAIL PROTECTED] Subject: RE: Perl fork question - SAPDB communications layer written for l onger running sessions Hi Stephen > -----Original Message----- > From: Stephen Gutknecht (SAPDB) [mailto:[EMAIL PROTECTED] > Sent: Donnerstag, 7. August 2003 22:19 > To: Dittmar, Daniel; '[EMAIL PROTECTED]'; > [EMAIL PROTECTED] > Subject: RE: Perl fork question - SAPDB communications layer > written for > l onger running sessions > Importance: High > > > I would add that our testing has shown what Daniel says to be > true. Using > Perl on Linux or using dotNet on Windows we find SAPDB to be > one of the most > unreliable and poor performing database systems :) I know that you have problems at your site with ODBC. However, the problem does not seem to be easily reproducable since you never send me some standalone code to reproduce it in my environment. All what you reported (into the list and directly to me) let me think that the reason for that is the driver. And I can assure you that I investigated a considerable amount of time to find the cause for that. Until now the problem apparently remains, what I regret. But without being able to reproduce problems, it's not so easy to find solutions. I can understand that you might be somewhat frustrated but I hope you exaggerated a little bit. > P.S. to list: Would US$5000 be enough to fund someone to > develop a native > and stable Windows dotNet driver for SAPDB in c#? There are > already ones > for MySql / Postgresql. Plus the SAPDB java driver should > prove a good > place to learn the driver-protocol from... It's good to see that some business is growing around our DB :-) Regards Thomas ---------------------------------------------- Dr. Thomas K�tter SAP DB, SAP Labs Berlin Hurry up, SAP DB is open source www.sapdb.org _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
