in reply to CGI MySQL script to ASP(perlscript) MSSQL

Thanks for your input. I'm using DBI::mysql at the moment. Ok, so I'll use ODBC, that should make things easier for end users. By the way end users will usually only have a shared hosting account. So installing extra features on the server isn't the way to go, i think that crosses out the FreeTDS option. So now it's really a case on syntax for the database calls. There are a lot of the because the program is rather large. Some of the calls are relational, with grouping and sorting, will it be a problem translating these? Do you know of a good reference that I could use to compaire the SQL syntax from MySQL to MSSQL through ODBC. I haven't worked with ODBC before, so I'm not sure on it's workings. My current thinking is that I'll write a routine that checks the SQL and makes any changes needed if using ODBC before the call. Will the syntax for getting returned data be the same? $sth->fetchrow_hashref, $sth->fetch(), $sth->bind_columns(undef,\$username), $sth->fetchrow_arrayref, etc? I guess I need a good code example for MSSQL through ODBC, do you know a good source for this?

2004-10-28 Edited by Arunbear: Changed title from 'Thanks', as per Monastery guidelines

  • Comment on Re: CGI MySQL script to ASP(perlscript) MSSQL

Replies are listed 'Best First'.
Re: Re: CGI MySQL script to ASP(perlscript) MSSQL
by jZed (Prior) on Oct 27, 2004 at 14:55 UTC
    All of the DBI things like $sth->fetchrow_hashref etc. should work identically with the possible exception of the case of the column names (I forget if there is a difference, but if there is, it can be solved by using the FetchHashKeyName attribute).

    As another poster mentioned, there will be some differences in datatypes. I don't know if MS-SQL supports MySQL extensions like the LIMIT clause. In terms of checking for these kinds of differences, I would recommend O'Reilly's _SQL_In_A_Nutshell_ - it's not the best SQL reference, but it does list implementation-specific differences for most commands. You could also try looking at some of the DBI extension modules that work on multiple databases and either use them or look at their code to see trouble spots. I've not used it but Rosetta claims to handle implementation differences. SQL::Translator ought to be useful for converting CREATE statements.

    In terms of testing, you can comment out all of your executes and just run the prepares of all your SQL - the prepare will let you know if there are SQL syntax errors without actually doing anything to the database. Better yet, create a dummy database and just run your script and see where problems (if any) crop up.