Good   Like I said, we'll be changing the threads to use the same principal as the spawning thread in the next release.  Oh, you're right, it's DataAccessLayerThreads, not the other... and like you said, yes, the default value is already 1.

Glad you got it going

Well, I tried it anyways since i thought the default value might well be 1. Guess I was lucky -> Now it works perfectly. Thanks a lot for your help!

Hi Ben,

thanks for your reply. In what Namespace/Class can i find that Property? I only found DataAccessLayerThreads but not DataLayerSavingThreads.

thanks

OK, it looks like there are a couple things that we can do to solve this problem.  First off, in 1.6.1, the DataLayer has been changed so that if the DataLayerSavingThreads property = 1, it does not spawn new threads.  Instead, it just uses the current thread (the one that called Save()).  The next thing is to save off the principal of the current thread and set the CurrentPrincipal on each thread that is created while saving.  So, looks like your problems will be fixed in 1.6.1.  The following link is to the latest DLLs that don't spawn new threads when that property = 1.  Put them on your server and let me know if it fixes the problem of saving.

http://forum.strataframe.net/FindPost9612.aspx

Well, I dont think the connection string is the problem. Since i use Integrated Security one Connection String for all is enough.

My problem is that the identity of the current user is not retrieved correctly within the StrataFrame CRUD methodes. Like I said the right Windows Identity is used when i use the Data Retrieval Methods of the StrataFrame BO and that one uses the same DbDataSourceItem(or not?).  But when i use the StrataFrame BO-Methodes to Update, Create and Delete it uses the Networkservice - Account rather than the Users Account performing the request.

I found this article that might be helpful to figure out why impersonation fails

http://pluralsight.com/wiki/default.aspx/Keith.GuideBook.WhatIsImpersonation

Since the connection string is stored within the DbDataSourceItem and that DbDataSourceItem is in a shared variable that is shared across the AppDomain, there isn't a way to impersonate users within the connections used by the DbDataSourceItem.  One of our users did setup his web server to use a different DbDataSourceItem per user (they're stored in a collection by key).  When the user logs in, he programmatically created a connection string using the users supplied credentials and added that new DbDataSourceItem to the database with the key stored in a session variable.  When the business objects were instantiated, he pulled the key out of the session variable placed it in the DataSourceKey property of the business objects so that each BO used the connection associated with its user.

Hi,

i got a webapp running under iis 6. its an intranet app that uses the following web.config settings to authenticate a user:

<authentication mode="Windows"/>

<identity impersonate="true"/>

This works fine for all my old manual CRUDs -> the user always gets identitied as its Windows Identity and since the Sql Server roles are linked to ntgroups they can perform the action based on the permissions set on the table/sp for the ntuser or ntgroup.

It also works when I use the Application Framework, but only with the Data Retrieval methods. If I perform an Insert/Update or Delete I always get an error that I am not allowed to access the Database. The reason for this is that the Application Framework ignores impersonation and runs under the standard account of the web app.

What do I have to do to get the Application Framework to use the right identity?