Migrate a SQL 2000 DB to a 2005 Server and IIS 6.0 to IIS 7.0.

Extra Issues:

- SQL2000 is full of procedures, views and identity tables (+200 each)
- Coder who built tables/procedures was lame, so there might be NULL values where it shouldn’t among with other things, like STRINGs being converted to DATE, INT, etc.
- Also includes lame asp coding.
- CRYPT MICROSOFT ERRORS (CRITICAL)

More Problems:

I don’t know why people still using microsoft, everything is against it. Not only the OS, but everything (ASP, SQL, VB, IE, Office, etc) related to microsoft is bad.

When you start to get those `error: XXXXXXXXX` like you know you’re screwed, why:

- Error codes aren’t clear and used by many different instances.. guess what, none of them will fit your issue;
- Microsoft KB isen’t accurate;
- Sometimes, Microsoft KB might present you the right answer, but it will be the last one on a list of 10 possible solutions, since they don’t have much control on the crypt errors themselfs, no wonder;
- Microsoft KB likes to do inaccurate automatic translations of the content (if your not english native), meaning that, if you eventually forgot that, you will be lead to another issue caused by the automatic translation.
- MSSQL don’t have `limit x` on delete/update queries, unless you do a huge workaround that will lead to more issues.
- IIS complies with MSSQL, also showing crypt errors, making the debugging impossible for non-computer beings (eg.: you).
- IIS crypt errors can be more funny when it simple shows `Bad Request`  or `Application Error` and NOTHING ELSE.
- IIS likes to get stuck, if you try to restart/stop/start/recicle a service that takes too much time to happen, IIS manager simply shows a message `Service not responding` and abort the operation, sometimes it abort the operation and a few minutes later it happens, other times it just don’t happen and/or get stuck then you need to reboot;
- Copying database straight from the 2000 server to a local 2005 server gives the following error: `Error, please check your log`; Checking `your log` gives lots, lots of crypt non-sense errors in my native language, guess what? 0 results on google.
- The error above takes 30 minutes to happen, nothing is copied, but there’s a 300mb .mdb file.
- If you do a `SCRIPT DATABASE` you will not get the whole data or/and tables will not have identity columns or/and some data may be corrupted (even deatched);
- If you do a `IMPORT/EXPORT` procedure, you will fall on the VERY SAME problems above, but now you may also get timeout crypt message;
- You can only edit top 300 lines on MSSMS, sorted by MSSMS’ will;
- [db_name].[dbo].[tbl_name] will not appear on the automatic generated scripts, but if you forget to add it your script will miserabily fail with a non-crypt error message (first time) — that only happens if you use MSSMS;
- Can’t stand that green circle looping;
- MSSMS 2005 and 2008 are about the same, meaning you will have the same errors, so don’t even try to update;
- SQL2005 SP3 must be installed before anything, unless you want to fall on unsolved crypt errors, leading to nothingness;
- You can also amazingly fall into crypt errors with ALSO typing errors like `erro XXXXXXXXX`;
- Screaming to the skies and throwing things around will not help;
- Reinstalling SQL Server will not help;
- Reinstalling SQL Server with latest SP will not help;
- Reinstalling OS will not help;
- Reinstalling OS with latest SP will not help;
- Reinstalling <Microsoft Software> with <Any Condition> will not help;
- IIS will not forgive and forget any `;` you put on a asp page, too bad for mainly php coders (eg.: me);
- IIS is for Apache as IE is for Firefox (is this understandable in english? don’t think so);

Another Complaint:

The triumph of a bad software can’t be explained for me, I can’t also understand why they made so much money on something that simply dosen’t work. Maybe users like
things that don’t work? Maybe there’s something magic on crypt errors and blue screens? Maybe Microsoft is paying developers to use their languages and/or software?

Solution:

After several days, tries and lots of time lost I was able to do the migration using MSSQL Enterprise 2005 SP3, the Developer, Express, SQL 2008, SP1 and SP2 gave me crypt errors when copying the database, nothing related to installing the latest SP was on the KB.
Note that i installed ALL versions to try. Thanks microsoft for such great support and programs, looking forward to support the selling of pirated microsoft dvds on streets.

Solution 2:

Move to LAMP, please.

Today I’ve spent over 2 hours implement jQuery on a old script I have, and I felt into so many issues that it didn’t worth at all.

My script was simple, I had a huge variable list that could be edited by a form, script loops through the variables building a form with input fields for each variable. I will not get into specific details because it’s boring, but I needed to allow the user to add a new variable inside an array, so i thought that jQuery would help a lot since i only would need to dynamic add a new input field as needed then post everything back to script to save the file.

First I spent an hour figuring out that jQuery was ruining the text by converting the whole thing into UTF-8, loosing all the accents, eventually I found out about contentType encoding ajax variable:

contentType:"application/json; charset=utf-8"

which could be changed to the charset i wanted.

It was useless, jQuery still posting into the wrong charset, there’s some other tweks on this, but they are also useless.

I was able to fix the accent issue with this php statement:

mb_convert_encoding(urldecode($variable),”ISO-8859-1″,”auto”);

This is much more obscure though, but I was familiar with it since i coded in japanese charsets which are a pain to convert.

After having this cleared, and searching a lot of useless blogs and postings, turns out that jQuery was using the hard coded form names to post the data, which could be overlapped by an dynamic added field, I did a script to change the name of the hard coded inputs, something like this:

$(“#field_id”).attr(’name’,’new_name’);

Theorically, it worked, but when I did:

$(“#form”).serialize();

jQuery used the dynamic fields with the ordinary hard coded ignoring the attr changes.

Now I had to add a handler to dynamic convert and read all the inputs and do my own serialize in order to TRY to make it work…and that’s because i didn’t tested it on IE yet.

So that’s when I quit using jQuery for this script and do something plain and simple, which took me about 20 minutes and 0 searches.

It looks like that if I had used DOM elements for the whole form, all elements generated by jQuery itself, not hard coded, i would have less trouble with the form, although, the charset issues still.

Super Fun Sources:

Stack overflow posting

Stack overflow posting 2

jQuery Ajax Documentation (completly useless since contentType explanation has 2 lines)

On a simple MSSQL (Microsoft SQL Server) with PHP you get this error:

Warning: mssql_query() [function.mssql-query]: message: Unicode data in a Unicode-only collation or ntext data cannot be sent to clients using DB-Library (such as ISQL) or ODBC version 3.7 or earlier. (severity 16)

and the best, it dosen’t matter if you convert the data to a different type.P>

Solution:

It looks like that mssql library at php can’t handle the ntext objects right, or at least the way you’re calling it is not right, the ONG>wrong way is:

function _connect_mssql() {
global $_msql,$_msql_id;
if (!$_msql_id) {
if ($_msql=mssql_connect(dbserver,dbuser,dbpass)) {
mssql_select_db(db,$_msql) or die("Unable to select database: ".db);
$_msql_id=1;
} else {
die("Couldn’t connect to database");R> }
$_msql_id=1;
}
}
function _qm($sql) {
global $res,$_msql,$_msql_id;
if (!$_msql_id) { _connect_mssql(); }
$res=mssql_query($sql,$_msql);
if (!$res) { die("Error on query: ".$sql); }
}

Those are simple functions to call it without using a class or too much paraphernalia. And it doesn’t work when the table has a ntext column on it, now a function that works with any type of table:P>

function _connect_mssql() {
global $_msql,$_msql_id;
if (!$_msql_id) {
$_msql=new COM("ADODB.Connection");
$_msql->Open("Provider=SQLOLEDB.1;Password=".dbpass.";Persist Security Info=True;User ID=".dbuser.";Initial Catalog=".db.";Data Source=".dbserver);
$_msql_id=1;
}
}
function _qm($sql) {
global $res,$_msql,$_msql_id;
if (!$_msql_id) { _connect_mssql(); }
$res=$_msql->Execute($sql);
if (!$res) { die("Error on query: ".$sql); }
}

$_msql="";$_msql_id=0;

Note that I used a class and ADODB connection instead, this works prefectly.

Accents (á,à,ã,etc) not working on vnc viewer, for example:

instead of  á it shows  ”a (double ‘)

Solution:

I’ve been looking around for a long time to fix this issue, i haven’t found any relevant information about it.

So i decided to install a different VNC client program, turns out that TightVNC Fixed the issue.

Note that it will not work if you don’t configure your keyboard proprietly on linux, I write in portuguese and english, so as keyboard i have Generic International keyboard, as layout Brazil / Brazil.