|
Re: CGI MySQL script to ASP(perlscript) MSSQL
by jZed (Prior) on Oct 27, 2004 at 00:00 UTC
|
You didn't mention if you are using DBI. If you are, your transition will be eased, but not eliminated. You will still face the problem of differences in the SQL dialects between the two. If you are using relatively few MySQL specific features, you should be ok. I would recommend using DBD::ODBC for MSSQL. You can also use DBD::Sybase but as MSSQL diverges further from its Sybase origins (which MS has announced it will do), that option will become less viable. | [reply] |
|
|
| [reply] |
|
|
Thanks for clarifying. I hope no one misinterpreted my remark as in any way denigrating the excellent DBD::Sybase. If someone interpreted it as denigrating MS-SQL, well, I can live with that :-).
| [reply] |
Re: CGI MySQL script to ASP(perlscript) MSSQL
by elwarren (Priest) on Oct 27, 2004 at 00:17 UTC
|
It is very possible to run the same SQL against several different databases. The two biggest problems you'll run into will be making the initial connection to the database, and then datatypes in your schema.
There are several methods of connecting to an MSSQL database via ADO, ODBC, or the Sybase driver. In all fairness, you also have three methods to connect to MySQL as well. You should set a config variable on startup to choose what database you'll be connecting to, then an if/then switch can choose to execute the proper connect strings and setup your environment.
Once you're connected, you'll have some differing datatypes on these databases. Perl scalars will hide most of this from you, so you'll really deal with this problem more when you're porting your schema. For example, in Oracle we use VARCHAR2 datatype, but MySQL only has VARCHAR datatype. Oracle doesn't use the VARCHAR for some reason that is long forgotten. A forward compatability that was never introduced. The DBI driver hides all this from you as long as you're not doing something fancy. Judging by your request, I don't think you are. No offense intended.
HTH | [reply] |
Re: CGI MySQL script to ASP(perlscript) MSSQL
by Anonymous Monk on Oct 27, 2004 at 12:39 UTC
|
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 | [reply] |
|
|
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.
| [reply] |
Re: CGI MySQL script to ASP(perlscript) MSSQL
by cosmicperl (Chaplain) on Oct 27, 2004 at 14:26 UTC
|
The comment above from me by the way. Forgot to login. | [reply] |