> > Does a .NET driver has to be 100% CLR/C# or could you use > C++ libraries?
No, it doesn't have to be 100% managed code but that's my approach. My MySql driver is 100% managed and I have received many comments from folks appreciative of not being tied to a particular version of a client lib. > > 3. What does support look like for SAPdb 7.4 and earlier in > > light of the > > relationship with MySql? What I really want to know is will the wire > > protocol for communicating with Sapdb change as a result of > > work with MySql? > > I don't want to invest a good deal of time implementing a > > protocol that is > > getting thrown away. > > There won't be any major changes to the protocol. And these changes > will be mainly enhancements, old clients will remain valid. > > So be prepared to ignore new 'parts'. These are very rarely > added to the protocol, mainly to provide additional information (like > "last serial added") Understood. > > > 5. What docs are available to understand the protocol? If the the db > > running on Linux and have vtrace working. Also, I have the > > following url: > > http://sapdb.2scale.net/moin.cgi/NetworkProtocol > > > > I have looked at the sources a bit but could not really make > > good progress > > understanding the flow. I have been making ok progress with > > the protocol > > specs. > > VTrace is probably the most important tool. Be sure to use the > option 'diagnose vtrace ORDER on' to see the complete packet. > > You should also try the same statements with several clients, > as not all the clients use all the features of the protocol. For > example, the Precompiler and ODBC read LONG values by requesting > several values at once for maximal throughput, whereas JDBC and > Python read each LONG value separately for maximum flexibility. > ODBC and Python don't implement batch inserts at the protocol > level. > > Some hints if you really want to create a 100% C# driver: > - start with the transportation layer to connect to > dbm server. The application layer of the dbm protocol > uses UTF8/ASCCI, so it's easy to implement. The > transportation layer can best be learned from the > JDBC sources (com.sap.dbtech.rte.comm > - write your own packet trace, this is always a great > learning tool > Thanks for the info. I'll continue to post here as I make progress. It may be slow go at first since I just started another project and will be working on this as time permits. one thing that I am not understanding from the docs is the difference between var_size and var_length in the message header. I understand var_len is the byte count (rounded up to a boundary of 8) of the message. var_size reads to be much larger. The document seems to indicate that the message block is much larger than the actual number of bytes needed however I can't believe that dummy bytes are sent as that would be a huge waste of bandwidth. The docs seem to indicate that this was done to "reuse" the message packet in future messages, however I don't see how simply specifying a longer message size accomplishes this. <rant> I must say I do appreciate the much more specific (though more verbose and bandwidth wasteful) protocol compared with the protocol in MySql 4.0 and earlier. My provider has a few significant hacks used to interpret the meaning of a packet when it would have been so much easier for the server to simply tell me this is a rowset packet, this is a schema packet, etc. </rant> Reggie -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
