Menu
▾
▴
Re: [Tcl-tdbc] Slowly (VERY slowly) writing Tdbc driver for Sybase
|
From: Tomasz K. <tk...@gm...> - 2009-04-26 09:50:43
|
I know that Dossy did some work for AOLserver database driver stack concerning Sybase & MSSQLServer. I haven't dived into details to add anything useful to your discussion by myself so I would like to only notify you about this. Regards, Tomasz Kosiak ---------- Forwarded message ---------- From: Kevin Kenny <ke...@ac...> Date: Sat, Apr 25, 2009 at 5:26 AM Subject: Re: [Tcl-tdbc] Slowly (VERY slowly) writing Tdbc driver for Sybase To: hyt...@gm... Cc: tcl...@li... hyt...@gm... wrote: > First, this is something I'm doing on my free time as a learning > exercise--which is a couple of hours a week if I'm lucky--so if > anybody is already doing it please cut in and spare me the trouble :) To the best of my knowledge, nobody is working on a Sybase driver, which if done right would also provide the foundations of a native SQL Server driver. > The plan: > - Develop against the ctlib distributed with ASE 15's x86 distro, > using Visual C++ Express 2008. I'll provide both an nmake makefile > and the express's project file. OK as far as it goes. We'll probably also want a mingw equivalent, but someone else can handle the port once the base is done. > - Keeping FreeTDS in mind, try (if possible) to stick with only the > ctlib routines actually supported by the latest stable FreeTDS distro. > - Stick with Sybase 10's TDS, for backwards compatibility. That's fine, too. TBDC uses prety vanilla stuff, I doubt it needs anything that isn't "lowest common denominator" > - Use Sybase' pub* databases for accompanying unit test code. Uhm. Ok. If you look at the test suites for the three drivers now in existence, they all start with an empty database and do their own CREATE TABLE statements. Of course, there's no need for the database to be empty, as long as the created tables don't collide with stuff that's already there. The three test suites borrow large amounts of code (and the test numbers) from each other, and I'd kind of like to keep the tests as uniform as possible. But use your judgment. > - No support for DBLib. At all. I remember DBLib. With no particular affection. > What I'm concerned about: > - Null handling. This seems to be an open question. Any particular > reason why this can't be a method in one of the TDBC objects (e.g., > the resultset)? TIP 308 defines the semantics of NULL quite explicitly and is consistent about it. The only 'open question' is what to do about the incessant complaints from a few users who don't agree with it. > - Big/Little Endian concerns, especially when working across different > platforms. I'm not sure how seamless this is and how much I have to > do on my own.. I presume you mean with the database API? Tcl hides endianity from you, and I seem to recall that TDS does as well. > - Internationalization. I think Sybase has a Japanese pub, but I > don't read Japanese so I'm kind of stuck there :) Tcl's internal character representation is UTF-8. If you can configure the API so that strings are UTF-8 throughout, you're home free. Otherwise, Tcl has a rich encoding conversion system, and we *do* have users who are literate in Japanese (Chinese, Korean, etc.) who can advise and check you. > Hopefully, the developers manual will answer most of my questions and > concerns. Thanks for taking this on, and welcome aboard! I'm very glad to have you with us. I suggest a few things: - Subscribe to the 'tcl-tdbc' mailing list at SourceForge and ask questions there. It's *very* low volume, don't be afraid to join. - Get TIPs 308 (http://tip.tcl.tk/308) and 350 (http://tip.tcl.tk/350) and try to understand them. They go into considerable detail about the API that a driver needs to present. - Go to http://tdbc.tcl.tk/, login as 'anonymous' with the password that appears on the login page, and follow the instructions to download the source ZIP. The source code for the ODBC and MySQL drivers should give a decent idea what is to be implemented. There are also comments in tdbc/library/tdbc.tcl about what methods a driver needs to support. - Look through the test suites of the drivers. It's useful to develop a piece at a time, with the goal to get more tests working at each stage. The test suites are structured around this idea; the earliest tests are "easy" (requiring only opening/closing database connections), and then they get "harder" as you go along. I suggest initially treating all database values as character strings and deferring data-type specific conversions to the very end of the development cycle. Let me know if you need help! -- 73 de ke9tv/2, Kevin ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Tcl-tdbc mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-tdbc |
