I have reinstalled 1.6.7 beta three times now and this field is not created in my database. Please help.

If there is a no immediate package available to fix this, can you tell me how to manually create this field if you think that will allow me to deploy my triggers?

Keith Chisarik

From looking at the class definition of TriggerInfo I am missing a few more fields from this table as well.

Keith Chisarik

I manually added fields (not feel to good about this) to the SF table according to class definition TriggerInfo and it works. Wondering why I didnt get them upon deploy, and want to make sure I got them right and that I am good to move forward.

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.

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

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?

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

 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.

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