Tracking changes and thread security


Author
Message
MarcoR
MarcoR
StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)StrataFrame Beginner (23 reputation)
Group: Forum Members
Posts: 15, Visits: 39
Hi,

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!

Reply
Peter Denton
Peter Denton
StrataFrame User (147 reputation)StrataFrame User (147 reputation)StrataFrame User (147 reputation)StrataFrame User (147 reputation)StrataFrame User (147 reputation)StrataFrame User (147 reputation)StrataFrame User (147 reputation)StrataFrame User (147 reputation)StrataFrame User (147 reputation)
Group: Forum Members
Posts: 77, Visits: 787
G'day

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

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search