I'll add to Ivan's comments (all good), having done something like this...
- If you are simply replacing the default instance of SQL Server with another default instance (I.e. you uninstall express, then install developer version), and you use the same user/password (or use windows auth) between the two installations, you'll be able to use the attached db no problem. If any of this is different, you'll need to change the database connection for SF in VS and you'll need to reconfigure you projects the business mapper.
- If you're not using windows auth (you're using SQL auth), then you'll need to create the user name(s) in the new instance and after you attach your database, delete the user(s) form the database and readd them using the newly created users. I.e. if you are attaching to the StrataFrame db as edhy in SQL Express, the process (related to this issue) would be to: detach the StrataFrame db, uninstall SQL Express, install Developer version, attach StrataFrame db, add a login for edhy to SQL server, delete the edhy as user from the StrateFrame db, add edhy back as a user of StrataFrame. Remember to keep the user's passwords the same (see above). This only applies to sql auth (non sa users...if you are attaching as sa, then you don't need to do this). This is needed because SQL Server actually uses an internally generated GUID for each user. When you move the database (by detaching/attaching), the database is tracking the GUID. So even though the user name and password match in the new db, the GUIDs won't.
- If you use VS when the StrataFrame database is unavailable (like in the middle of the database switcheroo), expect it to open very slowly and expect any work in form designers to be very slow, even if you are working on non SF projects.
- If you detach your databases and move them to new locations, you can sometimes have trouble attaching them through either SQL Server Management Studio, or worse, it does something unexpected. When you attach via SSMS, it expects the log file to be where it was when it was detached. So, if you move the main mdf file, one of two things can happen, depending on what you do with the log file. If you leave the log file in the old location, it will be used (typically occurs if you just copy the mdf and ldf files to the new location). This is especially bad if you copied the ldf file (not moved it), as you might not catch it and back up the wrong log file. If you moved the ldf file or deleted it, then the attach will just fail, saying it can't find the log file (even though the log file is sitting right there next to the mdf...sigh...you'd think they might be able to use relative paths). If you run into this, use this sproc to attach the file:
exec sp_attach_single_file_db 'dbName','c:\FullPath\to\database\file.mdf'
This will create a new log file if the one referenced within the mdf isn't found. Typically, I'll follow this process to move/rename an mdf: backup the database, open the properties to the database I'm about to detach to make sure I know where it is (
), detach it, delete the log file (just did a full backup, so this is OK), move it, run the above sproc, mess with users (see second item), update configuration of VS/BO Mapper if needed (see first item).
You may have already known all of this, but all of these have bitten me, so I thought if you didn't know, it might save you a bit of pain
