By Keith Chisarik - 2/13/2008
I have a web project that deploys DDT package files to databases via the DatabaseMigrator class.
I haven't touched this in weeks and it was working, now the database is created but the tables are not deployed. Were there any changes to this class in 1.6.5 that might have caused this before I rip it apart? To the best of my knowledge the SF upgrade is the only thing that has changed in this area of the project.
Thanks.
|
By Trent L. Taylor - 2/13/2008
Were there any changes to this class in 1.6.5 that might have caused this before I rip it apart? Only one line of code....which should not have any impact on this. We added a line that sets whether or not the column is a RowGuid column. But if there were some error it should show up in the log file that gets generated. I would be really surprised if the update had anything to do with this. I would start with the log files and go from there.
|
By Keith Chisarik - 2/13/2008
Hmm where does this log file get generated?
|
By Trent L. Taylor - 2/13/2008
By default it should be in the same location as the package file with a name like MyPackage_Results.log. You do have to turn on logging though:Dim mg As New MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator("MyConnection", MySyncObject)
mg.EnableLogging = True
mg.LogFilePathAndFileName = "c:\CustomPathandFilenameHere.log" I am pretty sure that if you don't set the LogFilePathAndFileName that it will just use the defaults (same folder location as the PKG file and the naming schema mentioned above.)
|
By Keith Chisarik - 2/13/2008
0oooooo logging, I would have pretty much loved to know that was there, I think DatabaseMigrator was skipped in the documentation phase?
Anyhow....."fld_RowGuiD" ?
• 2/13/2008 1:56:10 PM -> Deploying meta-data for database 'ioi_oo6972'
• 2/13/2008 1:56:13 PM -> The database 'ioi_oo6972' was created successfully.
• 2/13/2008 1:56:13 PM -> Ensuring Filegroups exist on database 'ioi_oo6972'
• 2/13/2008 1:56:14 PM -> Filegroup verification complete.
• 2/13/2008 1:56:14 PM -> Ensuring Tables exist on database 'ioi_oo6972'
X 2/13/2008 1:56:14 PM -> An error occurred while deploying the meta-data to the server.
X 2/13/2008 1:56:14 PM -> ArgumentException
X 2/13/2008 1:56:14 PM -> Column 'fld_RowGuid' does not belong to table DBEFields.
X 2/13/2008 1:56:14 PM ->
X 2/13/2008 1:56:14 PM -> Source : System.Data
X 2/13/2008 1:56:14 PM ->
X 2/13/2008 1:56:14 PM -> Stack Trace:
X 2/13/2008 1:56:14 PM -> at System.Data.DataRow.GetDataColumn(String columnName)
X 2/13/2008 1:56:14 PM -> at System.Data.DataRow.get_Item(String columnName)
X 2/13/2008 1:56:14 PM -> at MicroFour.StrataFrame.DBEngine.SQL.FieldInfo.get_fld_RowGuid()
X 2/13/2008 1:56:14 PM -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.CreateSmoColumn(Table ColParent, FieldInfo ColInfo)
X 2/13/2008 1:56:14 PM -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.CreateSmoTable(Database TblParent, TableInfo TblInfo, Boolean TempTable)
X 2/13/2008 1:56:14 PM -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.EnsureTables(Database TblParent, DatabaseInfo DbInfo)
X 2/13/2008 1:56:14 PM -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.EnsureDatabases()
X 2/13/2008 1:56:14 PM -> at MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.DeployMetaDataThread()
X 2/13/2008 1:56:14 PM ->
|
By Keith Chisarik - 2/13/2008
I also get this when trying to view Stored Procs within the DDT.
Thanks.
|
By Trent L. Taylor - 2/13/2008
You did not update your StrataFrame structures when you loaded the last update (or whichever server is housing the StrataFrame database). There are new fields that are used, such as the fld_RowGuid property. Just reload the latest 1.6.5 build and be sure to update the structures...or take the StrataFrame.pkg file in the C:\Program files\common files\microfour\strataframe folder and deploy it to the appropriate server. I have attached the latest PKG file so that you are sure to have the most recent version.
|
By Keith Chisarik - 2/13/2008
OK I will but I did the installs myself and and surprised the servers are not updated, in fact we have two in-house SQL Servers and I remember trying to remember the 2nd time which one I did the first 
Why does the package file need to access the SF database when it is being applied to a project database? I don't want to have a SF database at all on the server this will eventually be deployed to in production as this project doesn't use SF for anything other than this one function.
Thanks.
|
By Trent L. Taylor - 2/13/2008
Why does the package file need to access the SF database when it is being applied to a project database? It doesn't, but the field names from the StrataFrame database get exported into the DBETables.xml housed within the PKG file that you produce. So really, now that I think about it, you may just need to rebuild your package file since there are new fields that will end up in here...so your StrataFrame database is probably OK, but you more than likely did not rebuild your package file, which now looks for new fields, which caused the problem. Rebuild your package file and try again.
|
By Keith Chisarik - 2/13/2008
I had rebuilt the package before I posted, my SQL tables do not have the new field (why I cannot imagine), what is the password for the SF package file you posted please?
|
By Trent L. Taylor - 2/13/2008
what is the password for the SF package file you posted please? framework
|
By Keith Chisarik - 2/13/2008
Installing that and rebuilding after worked. Thanks.
|
By Trent L. Taylor - 2/13/2008
Cool 
|
By Keith Chisarik - 3/21/2008
Instead of starting a new thread.....
The NameOnServer property does not seem to be working for some reason, I wrote this months ago and now it isn't working.
I have these two lines of code that used to allow me to deploy a given package file to a SQL Server with any name I choose.
Dim loDatabase As New DatabaseTargetName(profilename)
loDatabase.NameOnServer = dbInstanceName
Now it is ignoring the second line and always applying to the SQL Server using the default name.
Help please 
|
By Keith Chisarik - 3/21/2008
My maybe this is due to my addins being messed up, should they read 1.6.5 now when I add a reference?
I see the file version is 1.6.5 and the Assembly is 1.6.0 (good stuff so we dont have to change all project references)
|
By Keith Chisarik - 3/23/2008
bumpity bump bump
|
By StrataFrame Team - 3/24/2008
When you're calling the DatabaseMigrator.DeployMeta-Data method, are you using the overload that accepts the array of DatabaseTargetName objects? If you don't pass them in, they get ignored...If so, then could you post the code snippet from where you're creating the name through where you're calling the deployment methods? Thanks.
|
By Trent L. Taylor - 3/24/2008
| My maybe this is due to my addins being messed up, should they read 1.6.5 now when I add a reference? |
You will definitely want to get this cleaned up as it will cause a number of issues since we did not change the assembly version, just the file version. If you can't get these removed from your assembly then manually use the gacutil.exe -uf command from the Visual Studio command prompt.
|
By Keith Chisarik - 3/25/2008
We had the package profile name wrong, it was hard to find the bug because it installed the default instance fine instead of blowing out. Thanks.
|
By Trent L. Taylor - 3/25/2008
Glad you tracked it down
|