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.


Keith Chisarik

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.

Hmm where does this log file get generated?

Keith Chisarik

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:

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.)

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   ->

Keith Chisarik

I also get this when trying to view Stored Procs within the DDT.



Thanks.




Keith Chisarik

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.

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.

Keith Chisarik

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. 

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?

Keith Chisarik