Scott Stewart

'copy mdf to bin' and ghost hunting.

I was playing around with a demo app today on a machine with just vb.express, sql.express, and all the current Winfx downloads; namely, to work a bit with the current WCF a.k.a Indigo stuff. I hate it when you want to test the waters in one area and spend hours stuck in something completely unrelated, but that’s just software development for you.

So, the demo app was supposed to be pretty simple. A couple of small business objects that made up the core of the application that are interacted with through a few web forms. The business objects would use a private tier for persistence with some predefined data contracts and service interfaces used to describe the messaging between the business objects and the persistence service; some simple Indigo demo stuff. The real point of the demo was just to demonstrate how the communication between the business objects and the persistence tier could be a) in process, b) classic web services c) remoting d) WCF/Indigo. It just doesn't matter. There are plenty of reasons to pick one or the other based on security, privacy, performance, current knowledge base, comfort, etc. So, besides for giving me an opportunity to play a bit with WCF, the purpose of the demo is just to reinforce old ideas: focus on getting the object modal right, the contracts and interfaces right, and as technologies change (ES, DCOM, Web Services, Remoting, Indigo) it just don't matter.

Here is where we get to the part about "want to test the waters in one area and spend hours stuck in something completely unrelated". When creating the persistence tier, I added a data source, so that I could take advantage of some RAD TableAdapter fun. The persistence tier wouldn't be working with datasets, but if the designer could save me time by creating TableAdapter goo code and procs, etc. it seemed worth it. When adding the datasource to set this up, I was prompted by a question something along the lines of "the database associated with this datasource isn't part of the project/solution would you like to include it." and then some warning that I ignored. Later on, after finishing the demo app and testing it, feeling pretty good about how quick the whole thing went, I was dismayed to find that my data was never really getting persisted in the database. It appeared to when I was debugging the persistence tier, and I would successfully insert new rows, get new identity keys back and the whole nine yards. But, after debugging, I'd look in the database, and there would be no data. Hmm. I tried it again. Same thing. It all had the feel of transactional stuff rolling back, but after debugging a bit further it didn't look like this was the case; especially since in frustration I removed all transactional wrappers!

A few hours later, I realized the root of the problem was my choice of "copy database to my local project" and then ignoring the part about this meaning the mdf would be copied to the bin directory each time. Wow! How could I ignore that? I guess its just that we press "yes", "I accept', "OK", etc so many times a day that most times we ignore the full content. Anyway, I guess the statement "If you copy the data file to your project, it will be copied to the project's output directory each time you run the application. Press F1 for more information." is not something you should click "yes' to without fully understanding the implications! Here is the "F1" link

So, in the end it turned out to be all my own doing, and just behavior by design (although, I haven't yet stopped to figure out how this would ever be desired behavior.) And after a few hours of attempting to troubleshoot what was going on with the TableAdapter.update method, which I must not have fully understand, I finally realized that it had nothing to do with the TableAdapter.update method :-). Never, in my wildest dreams, did I assume that a fresh copy of my database was being made to my bin directory every time the application was recompiled and run! Ah, chalk it up to the fun of software development. While others spend their weekends skiing, hiking, or driving racecars, some of us choose to chase ghosts in only a way that a software developer can really appreciate.