Ok. This Is My Closing Blog

I think I'm done. And no, it doesn't work. I didn't get Textpattern to work on MSSQL and I concluded I wouldn't be able to do it within the time given.
So anyway, this is to answer the 3 questions emailed to me this morning.
1. No I didn't get any part of Textpattern up and running. Textpattern loads everything it needs and there is one function to push everything out to the browser. So if any part of the code fails, you'll get a 404 or 403. Which is cool. In a way. hehe.
2. I'm rather shy to upload the lobotomised-cause-i-was-desperate version of the code which is failing on the hosted machine (which you can browse at http://zam3858.dev.lamp2win.com/). So I took out a this-one-makes-me-smile-kind-of version which I did earlier on. Minimaly lobotomised version ;).
3. Changes. Okay... let's see:
a. ./textpattern/txplib_db.php - replaced with the one taken from textpattern's crockery unstable version. They seem to be starting to work on supporting multiple database types.
b. ./textpattern/mdb.php - also taken from crockery.
c. ./textpattern/mdb/my.php - added a log function to capture all queries so that I could check for any which could cause problem to mssql.
d. ./textpattern/mdb/ms.php - this is where mssql functions would be. This one I adapted from my.php. It would be useful if the queries passed to it were database neutral (if there is such a thing. SQL standards, like html standards, doesn't always agree with the database implementors). So MSSQL doesn't have LIMIT (you get a funky TOP word with some funkier nested selects to get that one).
e. ./textpattern/index.php - just a minimal change from $connected to $DB->connected on line 129.
 
MSSQL vs MySQL query difference in Textpattern
basically there are 2 things in Textpattern that MSSQL says no to and that's unix_timestamp() and LIMIT. This is scattered in various places in Textpattern because Textpattern doesn't use a sql statement generator so it they did code this manually. No problem for them but I really had problems with these. I didn't feel like doing an if/else on each of them to maintain operability with the types of servers. I have to admit I found out about this a bit later and I estimated i wouldn't have time to properly change this.
hmm... I think I could've try create a stored function name unix_timestamp() and put in a function to return the unix timestamp from the query like I found googling on the net. But it's already too late for that. I will still have to deal with LIMIT.
Of course, everybody (i think) had fun changing auto_increment into IDENTITY(). Then (thanks fradze) inserting initial data with identity_insert on (i didn't get this before fradze pointed it out. I did it backwards, i turned off the identity_insert then after the queries, turned it on. tired mind. hhehe).
MSSQL didn't like the ` . MSSQL uses the [] instead for safe field name reference. ` allows us to user reserved keywords as fieldnames for our tables so that MySQL doesn't mistaken user as refering to some other 'user'. [] does the same in MSSQL.  This was simple enough to fix using the editor's find-replaceAll. I used Netbeans, by the way, to help find stuff in multiple files. Luckily Textpattern didn't use anything that MSSQL could say as a keyword.
I mentioned Unix_timestamp(). One of my attempt was to remove this entirely from the query and do a strtotime() at the php code instead.
 
PHP function difference
Some functions are missing and that I wont point out as you can get the list from php's manual.
I would like to mention the subtle difference that surprised me (cause I think they shouldn't differ):
mysql_result and mssql_result had different opinion on the number of parameters it took. mysql_result needs 2 and made the third parameter optional. mssql_result made it mandatory for all 3 parameters to be given. So when adapting, just give the third mandatory a 0 if they don't specify in in mysql (mysql defaults it to 0 anyway).
 
 
Migrating Tip
Just because I failed doesn't mean I can't share some tips :p
Basically this is how I would do it if in the future someone comes to me with an app and pays me a million bucks to migrate.
- use a library. ADODB was suggested by several people including in Textpattern's forum.
- make sure the library generates the SQL statement to be passed to the server. SQL is a standard but nobody ever gets jailed for not following this standard. So lets just tell what we expect and the library pumps out the query to the database. Yeah... like cakephp ;).
- Keep data on the database but let php/ruby/python/whatnot do the manipulation. I mean if you save something as data time but wants to display as timestamp, let the coding language do the changing into timestamp. It has more functions for manipulation anyway.
- you might want to save everything as the basic datatype in the database and let the application handle validation. I think many will disagree with me on this but really, not all validation functions are available or the same in different databases. Heck... MySQL didn't have referential check till later so might as well code/check this at the coding level. Sure there's coding quirks as well but I think you can get around this easier. Especially if you just have a web interface to play around with your database and it times out everytime you scream eureka!
That's it! At least these are the stuffs I remember/can think of right now. Hope someone will find it helpful and could know what to look for.
Lastly I would like to thank all lamp2win for the sportmanship, sharing and overall being the OSS nice guys. I also like to thank the good people in Textpattern for the pointers.
May the best man/team wins!