This is from the end of the deployment log:



• 7/10/2008 2:00:39 PM   -> Finished verifying databases on server.

• 7/10/2008 2:00:39 PM   -> Executing Post-Deployment Scripts

• 7/10/2008 2:00:39 PM   -> Executing Post-Deployment Scripts - Complete

• 7/10/2008 2:00:39 PM   -> The meta data conversion to the SQL Server has been completed.

X 7/10/2008 2:00:39 PM   -> An error occurred while deploying the data to the server.

X 7/10/2008 2:00:39 PM   -> InvalidOperationException

X 7/10/2008 2:00:39 PM   -> The connection was not closed. The connection's current state is open.

X 7/10/2008 2:00:39 PM   ->

X 7/10/2008 2:00:39 PM   -> Source : System.Data

X 7/10/2008 2:00:39 PM   ->

X 7/10/2008 2:00:39 PM   -> Stack Trace:

X 7/10/2008 2:00:39 PM   -> at System.Data.ProviderBase.DbConnectionInternal.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)

X 7/10/2008 2:00:39 PM   -> at System.Data.SqlClient.SqlConnection.Open()

X 7/10/2008 2:00:39 PM   -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.DeployDataThread()

X 7/10/2008 2:00:39 PM   ->





Notice it was successful. I'm using the dataprogress.vb form class from the demo source for database installer sample. I'm guessing something is not getting cleaned up properly but I'm not sure what.



My code that calls the form is thus:



' Update database

Dim loData As New DataProgress()



''-- Show and install database changes

dr = loData.ShowDialog()

loData.Close()

loData.Dispose()



I added the code to close and dispose the progress form so that I could delete the package file. Unfortunately, I'm not sure if this is where the problem started...

One thing I would look at is if you are deploying both structures and data, re-create the DatabaseMigrator class between the two to see if the error goes away.  That would ensure that the connection is closed and re-opened.  That would be the first thing that I would look at.

Ah, good thought. I am deploying data and I didn't even check to see if the data from my 2 tables was successfully deployed. My guess is I won't see any data in those tables since this just shows metadata was successful, I bet you're right, it's trying to deploy the data next and that's where it blows up. I'll take a look in the morning and let you know.



Thanks!

Yep, it was the data deployment. I haven't fixed the code yet but these 2 tables are not actually needed just yet so I just removed them from the package for now to test and that got rid of the error.



Thanks again,

Randy



P.S. Looking forward to meeting you guys next week and learning lots of good stuff.

We look forward to meeting you as well...it will be nice putting some faces with names

Hi Guys,

I'm running into this issue as well, I am disposing of the database migrator class and still get the issue when trying to run a second deployment, any ideas ?

Yeah, I reproduced this and it should fix the issue if you dispose and recreate the object between deployment phases.  When you say, "Dispose()" are you re-created the object.  Also, to prove this, create a test that only does the second part and skips the first to prove that it is the instance issue or if you are fighting something else.

Hi Trent,

Hope you had a good Thanksgiving and time off, I am disposing and recreating the class as follows. I do not get the error consisently (of course never get it on my dev machine) just ocasionally on all different machines and if I rerun the deployment on the machine that errors it works without a problem. It is possible I have a version issue or something as  I made the dispose change after reading this post so the problem children might be running old software. Last week was a short week and I was in hurry to get out for opening day of duck season and I released several new things at all at once so I probably missed updating something. Anyway's I will see if the issue persists and if so I will try to narrow it down a bit better.

 

 

Well, this is all threaded.  So it is possible that you are running into a threading type of issue.  One thing to consider is a Threading.Thread.Sleep(NNN) after the dispose and prior to re-creating the object.  If you have a machine that you can reproduce this on, that is where I would start testing.  So get it in a reproducable state, then start playing with timing issues to at least see if that is your issue.  If it is, then you can remove the Sleep and take a better approach depending on your code. 

One other idea that I had was to create a nother variable for each phase altogather.  So you would have one for the meta-data and another for the data.  This is just an idea, but I would imagine that it would resolve the issue as well.

Hi Trent,

I like the idea of another variable, it makes sense. Anyways I guess I will find out on the next release how that does .Thanks again for the help and ideas.