Well, my entire DB uses InnoDB, so that kills using CHECKSUMTABLE.
Back to my OP...
How likely would it be for mysqldump to...
a.) Corrupt a Table Definition (i.e. DDL)??
b.) Corrupt a given record (i.e. INSERT)??
c.) Drop records (i.e. INSERTs)??
d.) Otherwise screw up the SQL that rebuilds a Database from scratch??
Here is what I ended up doing in my current situation...
1.) On my old MacBook, ran mysqldump.
2.) Placed the resulting .sql file onto a thumbdrive.
3.) Copied the resulting .sql file onto my new MacBook Pro.
4.) Ran the command to import the .sql file into my shell "doubledee" database.
5.) On my new MacBook Pro, ran mysqldump on the new database
6.) Used the app DeltaWalker to do a "File-to-File" (byte-by-byte) comparison of the to .sql files.
This entailed scrolling through line by line of the two .sql files in side-by-side panes and looking for where differences were highlighted.
Fortunately, according to DeltaWalker, my two .sql files were identical, except for some minor things like the SQL keyword being "default" in the original database and getting changed to "DEFAULT" in the new database.
Bottom Line: Using the above approach worked fine for my Dev database, but on a Production database with tens or hundreds of thousands of records, or even millions of records, that approach isn't realistic...
And since I am a big advocate of Open-Source Software, I'm not overly inclined to go buy software to do what I want...
I think one of my fundamental questions is...
How reliable is mysqldump - especially with large databases???
If mysqldump "just works", then I guess trusting it is enough.
Then again, I thought that I could trust phpMyAdmin after lots of luck with it in the past as a tool to at least manage my database.
Boy was I wrong about phpMyAdmin being "reliable"!!! :eek: