Actually, that is a bit strange.  The tr_Schema was a temporary field that was in the DDT a long time ago and is no longer used.  It seems like you may have an older package.  Regardless, we are posting a pre-release build (1.7.3.4) in the My Account area here in just a bit.  There have been a lot of fixes and this should make sure that this doesn't crop up.  This is ringing a bell and looking back at some of the fixes, I think that this update will resolve your issue.

We have been running and releasing this build, so it is fully supported and stable.  We will make this more official in the weeks to come.

This has recently become an issue for me as well. Some info that may or may not help... At one point we set the collation to be case insensitive which had all sorts of problems on the deployed database. One of the biggest items I noticed was that triggers could not be enabled/disabled. I've switched it back, added a new field to a table and assigned it as the primary key, int, auto increment after making the original pk on that table a regular field. Not sure much else has changed but now I'm getting this error.

Is there an official response on this? Could it possibly be fixed by somehow resetting the whole database back to square 1? Meaning that it would just create the database as is without going through any additional scripting to make all the incremental changes that have happened? This would only work for me because I have'nt officially locked in our schema anywhere yet. If I were into it then I'd need another fix.

My thought is... "Could it have something to do with incremental changes that have somehow confused the deployment?"

Matt

Hi,

I have a same problem

I had create 2 new triggers and try to Deploy it to SQL Server database.

THen during deployment I'v got an error



An error occurred while deploying the meta data to the server

ArgumentException

Spalte tr_Schema gehoert nicht zu Tabelle DBETriggers.

Source : System.Data

Stack Trace:

bei System.Data.DataRow.GetDataColumn(String columnName)

bei System.Data.DataRow.Get_Item(String columnName)

bei MicroFour.StrataFrame.DBEngine.SQL.TriggerInfo.get_tr_Schema()

bei MicroFour.StrataFrame.DBEngine.SQL.DatabaseMigrator.CreateTrigger(Table triggerParent, TriggerInfo info)

bei MicroFour.StrataFrame.DBEngine.DatabaseMIgrator.EnsureTriggers(Table triggerParent, TableInfo tblInfo)

bei MicroFour.StrataFrame.DBEngine.DatabaseMIgrator.EnsureTriggers(Database Db, DatabaseInfo DbInfo)

bei MicroFour.StrataFrame.DBEngine.DatabaseMIgrator.EnsureDatabases()

bei MicroFour.StrataFrame.DBEngine.DatabaseMIgrator.DeployMetaDataThread()

I have double checked to make sure that there is not an issue here. We are in the process of getting the build finalized. So I will be posting a new build soon once the samples and docs are updated. However, I may post an interim build so we can make sure that this is not an issue on your side. I have tested this on VM as well as our internal development environment and so if there was an issue with an interim build, it has been resolved.



I will most likely do a build today just to test this before we release a final build which will have some additional controls and features implemented. This way we can ensure you do not have this issue moving forward.

This error occurs when your trigger wont deploy (at least in my case), I think it is trying to enumerate the fields to give a more descriptive message.  I still get the error but have been able to work around it by fixing my TSQL in each case. At first adding the table manually fixed it but now a trigger deploy error aborts the deploy.

Keith Chisarik

 I just finished creating a new DDT package using SF 1.6.7 and I get the same error (see attachment) when trying to deploy it.

Ok i removed the field I added manually when I had to modify a trigger.

Column 'tr_Schema' does not belong to table DBETriggers.

Keith Chisarik

LOL...I understand. So you received the error during the deployment of the data...that actually makes me feel better. What did the error say exactly, do you remember?

Just to confirm, what should the current file version be for the SF assemblies version 1.6.7 beta? I have everything as 1.6.6.9 in my GAC which is where my assemblies are referenced.

The version is also 1.6.6.9 in c:\program files(x86)\microfour\stratafram\assemblies

I scanned my PC, these locations are the only two instance of the SF DLL's besides individual bin directories, which I deleted to be sure.

The deploy from within the DDT is where I got the error referencing the tr_Schema field.

I downloaded the install from the site again this AM, saving to a new location.

I am OK now since I added the fields manually. but knowing they shouldnt even be there make me feel all icky inside.

Keith Chisarik

It should have worked on the deployment. I tested this and it did in fact work. Also, if this were widespread I am thinking that there would be some other reports. So what I am wondering is if an old package, for whatever reason, was not overwritten when installed. I have seen crazier things happen.



However, I just went and looked, and it appears that your SF assemblies in your GAC (or wherever they are being pulled) do not line up with the most recent SF build. The tr_Schema field is actually no longer used and is in the object history to be deleted. Since a trigger is associated with a table, the schema will match the table. So it was overkill. At any rate, this seems to be the root of your issue.



We are in the process of finalizing the SF build so there will be a new install within the next 7 days or so. Regardless, double check your GAC and other assemblies including the C:\Program Files\Common Files\MicroFour\StrataFrame to make sure that you do not have two sets or conflicting assemblies being used.