With the latest installment of the DragonAge series shipping soon (only 4 days from now… *wibble*), a resurgence of interest in Origins has gripped me. I’ve bee whiling away the odd hour here or there playing through the campaign again, with little hope that I’ll finish it this time either. There’s just so much to do and that’s without all the weight downloadable content (DLC) of the epic Awakenings or the character-specific adventures that have rolled out since then. But I digress…
I wanted to mess around with the Toolset again (which allows you to craft your own adventures if you’re willing to invest a lot of time, or to just poke around under the hood and see how BioWare crafted Origins) but as I was running the installer I realized that it wanted to install SQL Express 2005. 2005? That’s a bit out-dated, don’t you think? After all, I’ve already got a SQL Express engine running on my box to support my independent development inititatives with Microsoft Visual Studio 2010. Why on earth should I install another copy of SQL Server?
I knew from my own professional experience that SQL 2008 and 2005 are largely compatible for most databases (and 2008 even has a 2005-compatability mode you can set should things go awry…), I thought “why not see if we can make this work with what i’ve got already?” So, I ran a few web queries to make sure I wasn’t setting out on a fool’s errand, and I ran across this wonderful blog post by a bloke named Evan. Evan probably saved me and others hours of time with those steps, but they didn’t quite work for me. Why, you ask? Well, it comes down to the fact that once again, he wants me to use SQL Express 2005. I figured “meh, skip that step, i’ve got 2008 installed…” and just tried to install the 64-bit SQL Server Management Studio (SSMS) Express package. No luck. For reasons unclear to me, it rolls itself back 75% of the way through the install claiming that it was “interrupted.” After trying twice in a row, I gave up on that and decided to use ply my sqlcmd-fu (that’s the special variant of kung fu SQL Server db admins are taught by the wisened sages of their art) and bend things to my will.
Sadly, his proffered advice about using SQL scripts he linked to was rather full of fail. While it gave me some (most? all?) of the DB schema, it didn’t give me nearly enough of the data. I kept getting errors about missing IDs and and other inaccessible data from the toolkit after running his scripts. But a comment on the letter gave me exactly what I needed: the fact that BioWare shipped a full backup of the database with the toolkit. Well, of course they did. How much easier can installing a database get than to use restore a database backup (.bak) and call it a day?
The path to success for Win7 amd64, Steam, and SQL 2008 Express is as follows:
- SQL Server is installed, running, and responding to your queries. E.g: running: sqlcmd -S .\SQLEXPRESS -q “select @@version” from a command/powershell prompt will yield:
Microsoft SQL Server 2008 (SP2) – 10.0.4000.0 (X64)
Sep 16 2010 19:43:16
Copyright (c) 1988-2008 Microsoft Corporation
Express Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )
- You’ve got Dragon Age: Origins installed and you know where it lives. For example, my copy lives in ‘D:\Games\Steam\steamapps\common\dragon age origins\‘
- You’ve installed the Dragon Age Origins Toolset, but opted NOT to install the included 32-bit version of SQL Server 2005 Express.
SQLCMD to the rescue!
- Once you install the toolkit, you’ll find they’ve included the aforementioned SQL database backup file (bw_dragonage_content.bak) for you. For steam users, it resides in the tools\dbbak subfolder of your dragon age installation. Go search your computer for it and get a hold of the full path to that file. You’ll need it shortly.
- We’ll need to issue several commands to SQL Server, and we’ll use a console application called SQLCMD to do it. So open up an elevated command prompt or powershell prompt and execute the following command to connect to your local copy of SQL Server Express:
- Now, every database backup has a designated place in the file system where its data (files that usually end in .mdf) and possibly logs (files that end in .ldf) are stored. Most database restores assume that the files you’re restoring from the .bak should go back to where they were found originally, so we’re going to roll with that assumption. First, we need to see where those files are expected to be, without actually restoring anything. To do this, we’ll use a mode of the SQL “RESTORE” command called “FILELISTONLY” to get the logical and physical names of the mdf and ldf in the backup file:
- You should see near the end the logical and physical filenames of the .mdf and .ldf in the file (after of a bunch of staggered “—–” characters … this is the pretty-printing that would make the data look like a table were your console window wide enough, or were you to output the query results to a text file), e.g.:
- The name without the path is the “logical” name. The fully-pathed file is… you guessed it, the filename. Once you are armed with these, you need to make sure the physical path this .bak file will expect actually exists. Since we’re running a 64-bit version of windows, chances are high that the Toolset installer created the “\DAODB\Data” folder in your Program Files (x86) folder (where all good little 32-bit programs go), not your Program Files folder (which houses the 64-bit ones). Fixing this is a simple matter of cutting and pasting the “DAODB” folder from your Program Files (x86) folder and pasting it in the Program Files folder. Once the folder C:\Program Files\DAODB\Data exists in your local filesystem, you’re golden. Use Windows Explorer to do this — far simpler and faster than aborting your SQLCMD session and then re-starting it later.
- Now we have to create the database so the backup will have a place to be restored to! Run these commands in your SQLCMD session (the color-coding is provided so you can visually map the values you got from FILELISTONLY above. If for some odd reason these have changed, you’ll know where to put the new values):
- You probably won’t get anything by way of a success message, but if you don’t get an error, you should be good to go.
- Now all we have to do is restore their database backup! Tweak the paths to match your system and then run this in your SQLCMD session:
- This will take some time and you’ll see some output, and probably a few ‘upgrade schema’ comments, but at the end of it all you will have successfully created the database!
- That’s it for DB creation! Exit SQLCMD by typing:
- All that remains is to tell the Dragon Age Toolset how to find the database. (If you don’t, you’ll get an error that says it can’t connect. If you’re wondering why, it’s because when the Toolset installs itself, it installs a “named instance” of SQLEXPRESS that isn’t “SQLEXPRESS”that is To do this, run the “ConfigureToolset.exe” that is located in the tools directory (the parent folder of the ‘dbbak’ folder that houses the .bak file).
- It will open to the ‘Game Builds’ menu. That’s not what we want. Click [Next] to find the ‘Databases’ window. Once there, uncheck ‘Use the default database’ and then click the […] button. This will open the standard ‘Data Link Properties’ window that every Windows database admin knows and loves. Here, you will want to specify “.\SQLEXPRESS” for your server in #1, leave #2 alone (it should default to ‘Use Windows NT Integrated security’), and for #3, select the bw_dragonage_content database we just restored. Lastly, click [Test Connection] at the bottom and assuming all went well, you’re done!
- Click [OK], then click [Next] in the ConfigureToolset UI, and lastly click [Finish].
- Now you should be able to use the Toolset to your heart’s content on Windows 7 64-bit with SQL Server 2008. Yay!
SQLCMD -S .\SQLEXPRESS
RESTORE FILELISTONLY FROM DISK = ‘D:\Games\Steam\steamapps\common\dragon age origins\tools\dbbak\bw_dragonage_content.bak’
bw_dragonage_content C:\Program Files\DAODB\Data\bw_dragonage_content.mdf
bw_dragonage_content_log C:\Program Files\DAODB\Data\bw_dragonage_content.ldf
CREATE DATABASE bw_dragonage_content
( NAME = bw_dragonage_content, FILENAME = ‘C:\Program Files\DAODB\Data\bw_dragonage_content.mdf‘)
( NAME = bw_dragonage_content_log, FILENAME = ‘C:\Program Files\DAODB\Data\bw_dragonage_content.ldf‘);
RESTORE DATABASE bw_dragonage_content FROM DISK = ‘D:\Games\Steam\steamapps\common\dragon age origins\tools\dbbak\bw_dragonage_content.bak’ WITH REPLACE,RECOVERY
Caveat: I haven’t done extensive testing so I can’t vouch that running the Toolset on 2008 won’t cause some problems down the line. I’m a total n00b when it comes to the Toolset itself… I just happen to know a thing or two about Windows and SQL. ;-)
Afterthought: More advanced / picky users might want to relocate the files from the DAODB directory to somewhere else. in that case you’ll want to create the DB with different filename specifications, and then restore with the MOVE directive as such:
RESTORE DATABASE bw_dragonage_content FROM DISK = ‘D:\Games\Steam\steamapps\common\dragon age origins\tools\dbbak\bw_dragonage_content.bak’ WITH REPLACE,RECOVERY,MOVE ‘bw_dragonage_content’ TO ‘[preffered path]\bw_dragonage_content.mdf’ , MOVE ‘bw_dragonage_content_log’ TO ‘[preferred_path]\bw_dragonage_content_log.ldf’