Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
RE: SAPDB not competitive due to neglect of Win32 drivers
From: Stephen Gutknecht (SAPDB) (IML-sapdbi405.com)
Date: Fri Aug 08 2003 - 17:26:35 CDT
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
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
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
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
From: Noah J SILVA [mailto:noah.silvaatofina.com]
Sent: Friday, August 08, 2003 12:59 PM
To: Stephen Gutknecht (SAPDB)
Cc: sapdb.generallistserv.sap.com; sapdb.general-adminlistserv.sap.com
Subject: Re: SAPDB not competitive due to neglect of Win32 drivers
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...).
IS&T - Programmer Analyst
(215) 419 - 7916
"Stephen Gutknecht (SAPDB)" <IML-sapdbi405.com>
Sent by: sapdb.general-adminlistserv.sap.com
08/08/2003 03:35 PM
Subject: SAPDB not comptetive due to neglect of Win32 drivers
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
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
addressing a native port (not cygwin) in 7.4).
SAPDB is ahead of PostgreSQL in the native win32 port. But SAPDB is
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.
From: Koetter, Thomas Theodor [mailto:thomas.theodor.koettersap.com]
Sent: Friday, August 08, 2003 1:13 AM
To: 'Stephen Gutknecht (SAPDB)'; sapdb.generallistserv.sap.com
Subject: RE: Perl fork question - SAPDB communications layer written for l
onger running sessions
> -----Original Message-----
> From: Stephen Gutknecht (SAPDB) [mailto:IML-sapdbi405.com]
> Sent: Donnerstag, 7. August 2003 22:19
> To: Dittmar, Daniel; 'sapdbkomadev.de';
> 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
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 :-)
Dr. Thomas Kötter
SAP DB, SAP Labs Berlin
Hurry up, SAP DB is open source www.sapdb.org
sapdb.general mailing list
sapdb.general mailing list