Just new to this forum, so three completely different questions:

1. I get an error saying I am not authorized when trying to post a new topic to the StrataFrame Application Framework forum. Why is that?
2. We are using the StrataFrame business objects within a WCF web service and we are creating only one instance of that service. Are the business objects thread safe in this scenario?
3. My manager would like to see if we can log all changes made to fields in the database. So for instance: field myField was changed by user xx today from old value 'Something' to new value 'Something Different' . Can we track those kind of changes through the property setters on the business object? I know one option is hooking into the events fired when a property is changed, but I was wondering if there might already be a built in solution for this.

Thanks!

2)  Yes, as long as the WCF service creates a new instance of the business object for each request, say as a local variable within each of the exposed service methods (you don't want a shared/instance variable that is use by all web service methods).  Just make sure that you dispose of the business object when you have completed... easiest thing to do is use a "using" block.

3)  We do not currently have an auditing system built into the StrataFrame Role-Based Security, so the best way to implement that functionality would be through the field changed events on the business object.

In answer to part 3.

We use Visual Studio Team Foundation Server as our Development environment, and SQL Server 2005 as our database.

We don't have as much of a concern over database changes, but we were concerned about stored procedures. So we added an SQL Server Project into our solution. We then used SQL Server Management Studio to script all our stored procedures for the solution's database to seperate files, passed them through a vbscript filter that puts them in a form consistent with a new StoredProc script added to the project (basically stuff to check if the script exists and if so delete it before re-adding), added the source files into the project, and added them into source control. Now all stored procedure development and change is done in Visual Studio and the changes are tracked in source control. We have found this is easier than using SQL Server Management Studio.

We have since done the same for our views and triggers. I suspect that database changes could be tracked in a similar way as long as they can be done by Transact-SQL statements (although I suspect you won't want to drop the table and recreate it every time as happens with stored procs, views and triggers).

Peter

Agreed.  And, if you are using VSTFS, then you likely have an MSDN subscription, and have access to the Visual Studio Team Database Developer edition.  It's got even more stuff to manage creating sprocs and database objects within Visual Studio (even unit testing for sprocs).