Stories
Slash Boxes
Comments

Slash Open Source Project

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • Earlier this week, fellow Slash developer asked me whether I had any suggestions on doing a Sybase database interface for Slash 2.x. Here are my responses:
    I ported Slash 0.3 and 0.9 to Sybase System 11. I have not had the opportunity to do it for Slash 2.x due to other work commitments. The 0.x codebase is quite different from the 2.x codebase, otherwise I would be happy to mail it to you.

    I have considered contributing Sybase code to the Slash project, once I convert my sites to 2.x. I am more likely to run MySQL when we make that switch, however, because I am concerned with being able to contribute code that is useful to the widest possible constituency within the Slash community.

    If you are planning to do a Sybase interface for Slash 2.x, let me know and perhaps I can help a bit. One concern is that if you try to do this using DBD::Sybase, you have to be aware of the fact that DBD::Sybase does not generally allow new database transactions to be started while other database transactions are pending on the same connection. In the Slash 0.3 codebase, this required us to rewrite a number of low level routines and use Perl array processing. Not sure how much this would affect you in 2.x, but it probably will, at least to some extent....

    My initial comments weren't entirely clear because I used the word "transaction" when I probably should have used the word "statement". So, I followed up with additional clarification of some points:
    There are a number situations in Slash 0.3 and 0.9 where a SQL query is executed to provide values to a for or a while loop, while the body of the loop performs some other SQL function. Generally, Sybase returns an error like "Attempt to issue SQL statement with results pending." Quite often, the easiest way to solve this problem is to rewrite the code block to bring the outer result set into memory using Perl arrays, or some similar technique. This could turn out to be a large number of situations in the newer code bases, but I don't know that for certain. I suspect that this is still a fairly significant problem, since most SQL databases do not have this restriction, and Sybase developers often write applications with this specific restriction in mind.

    I don't know how much you have used Sybase in the past, but most people who hear this situation described say, "This is so stupid. Why did they do that?" The answer is that it really doesn't matter when you are writing an application from scratch, you just use the SQL Server to do more work you would do in Perl if you were using mySQL or Oracle. You do a lot more JOINs, etc. Your problem is that you are porting something that was written for mySQL, so you will have to deal with this architectural difference.

    There are also a number of semantic differences between Sybase and mySQL. Date and time handling is one of the areas where you will need to edit a lot of code. For instance, mySQL uses the NOW() function to assign the current date and time to a column. Sybase uses GETDATE(). Date and time format conversion is also expressed differently.

    Automatically setting the date and time column to the current time is certainly possible in Sybase, but it would probably be done differently than in mySQL. I think the most effective way to automatically populate it would be to write an insert trigger on the table which needs to have the column automatically populated. Triggers in Sybase are sometimes problematic because they make it more difficult to import data from other databases, for example. There are probably other ways to automatically set a datetime column to the current date and time, but many of them would not work consistantly across all versions of Sybase and Microsoft SQL Server, so I don't know them.

    I have a tendency to write Transact-SQL code that is compatible with Sybase 4.9.2 and Microsoft SQL Server 6.5 unless I am under time constraints or I cannot touch the application that is calling the Transact-SQL code. After this point in development, Sybase and Microsoft dialects of Transact-SQL started to diverge, and you have to keep the differences in mind when you code. I could illustrate this with examples, but many of the ones that are obvious to me are esoteric to people who don't use both Sybase and MS SQL Server all the time.

    If anyone has any questions about what I've said, or wants to talk more about using Slash with Sybase, feel free to mail me at dave_aiello at ctdata.com.

    --

    --

    Dave Aiello
    Chatham Township Data Corporation [ctdata.com]