I agree. I have more experience with MS SQL than mySQL, but there are some MS SQL specifics that can cause hiccups. But these hiccups can be avoided with a bullet proof project plan and excellent documentation. You may not be able to automate all the project procedures and a lot of the database re-construction, which is OK. Make sure you run a test system to see if the migration is successful.
Migrations are my specialty! Good luck, and don't be afraid to ask questions on the migration! -----Original Message----- From: j.urban [mailto:[EMAIL PROTECTED]] Sent: Friday, January 18, 2002 10:08 AM To: Tony Buckley Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Porting from MS SQL to MySQL > Porting a DB takes more 'than a couple of hours'. What about the written > procedures, the security mappings, the back up and recovery procs, the > fallback arrangements, the testing etc. Yes, porting a database that was written for MSSQL with no intention of porting can be a painful proposition. However, if you have control over how the system is developed, you can easily design the system to be compatible with EITHER MSSQL or MySQL (the differeces are well-documented). If you develop your system with porting in mind (ie the original post of "they'll develop in SQLServer and port it to MySQL later") porting should not take more than a couple of hours. You simply choose appropriate datatypes and don't use MSSQL-specific extensions... On Fri, 18 Jan 2002, Tony Buckley wrote: > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, January 18, 2002 2:14 PM > Subject: Re: Porting from MS SQL to MySQL > > What about the customer who asks a car company to make the vehicle's tryes > out of velvet? Would you go off in a huff if they refused and demand they > do it? There are obviously issues here that we are not privy to; there > *must* be logic behind the choice of SQLServer. Are they saying that mySQL > isn't upto it? > > Porting a DB takes more 'than a couple of hours'. What about the written > procedures, the security mappings, the back up and recovery procs, the > fallback arrangements, the testing etc. > > If you think E18k is a lot then ask for a detailed task plan with effort; > find out what they are asking you to pay for. > > The DB was described as 'fairly complicated' whatever that may mean. > Perhaps - and we are all guesing - there are remote data issues, views, > stored procs, java and god knows what else that all needs to be integrated. > > Bottom line when you get a quote is find out what they want to do task by > task and then cut it down from there. > > Tony > > > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
