LOL...glad you got it going!  Thanks for helping out, Greg!!!

Clay,



Glad you figured it out. I'd say that changing a default would be a bad idea...it'd break lots of apps out there



However, adding a setting (or two) to indicate that a sproc should be used for this function seems like a good idea.



My guess is that you'll need to handle the concurrency event, run that sproc yourself and then provide the appropriate UI for your users, in order to handle concurrency conflicts.



Well, that was fun!

Hi Greg

This is apparently what the problem was.

StrataFrame needs to make one of 2 changes. Either make this property default to FALSE or give you the option to use a stored proc instead of the DAL generating a raw select statement. The way that this is setup is going to cause anyone who uses stored procs for data access (which I firmly believe is the only way it should be done) a problem at some point. I've been using StrataFrame since it's inception and am very suprised I've not run into this before...and a little concerned that it is happending in production and just havn't heard about it yet.

Thanks much for your help!

Clay

What about concurrency? Did you try turning off the GetServerValuesOnConcurrencyException property on the BO? That is the only thing I can think of (and I'm using both of my brain cells).

The SQL Statement was part ofthe trace I ran.

Just prior to hitting the .Save(), I started a trace. There were 3 lines in the trace...the 3rd of which died.

1. The update stored procedure which ran fine w/o failure
2. An sp_reset_connection which ran fine w/o failure
3. The Select statement.

I have absolutely no idea where the Select came from and worse...no idea how to get rid of it.

So, were did that SQL statement come from? It looks like something from SQL Server Management Studio, not from the app (exec sp_executesql being the big hint on that one ). Is the SQL from debugging the data source? It looks like DAL generated SQL that would update a single record. I seem to recall that SF does this automatically after a save to make sure the it has the latest values off the server, but not sure.



I just spent some time looking at the DAL code and I don't see were that SQL could come from. There is one thing that I can see might cause this to occur: you are having a concurrency issue. In this case, I'm pretty sure the DAL would generate the indicated SQL to get the server values. To test turn off the GetServerValuesOnConcurrencyException. I'm not sure if this affects things when it is raising events.

Hi Greg

Yea...the key is the same accross everything. It was one of the first things I checked. I've not checked inserts and deletes b/c they never happen in "real life". With that said, I could rig something to try it.

All data access is performed via sproc. I purposely develop using a SQL User that has only EXECUTE rights on the sprocs to prevent these types of problems going into production.

The problem still comes down to the SELECT statement shown above. I can absolutely guarantee you that I didn't write it. I would never have named a parameter "@PARAM0=10024" My parameters are all either named for the Field name (@FIRST_NAME) or using a convention (@aiMyParam). I did do a global search of the solution to be sure and it did come up empty.

This has to be coming from somewhere in the StrataFrame DAL.

Hmmm...how do you load the BO? Via sprocs again? And they work fine?



Also, (although it's likely you've already checked) the BO is using the same data source key as the other BOs? You haven't done something funky with the data source have you? Use a different user?



Do your other sprocs work OK? The insert and delete?

Below are my BO properties.

Hi Greg

Thanks for the reply. I do everything under a role named db_executor which I grant EXECUTE to all sprocs but only that. The user SprocUser is a member of that role and nothing else. I've logged into management console using SprocUser and can run the sproc without a problem. Its the SELECT statement that causes it to puke. When I grant db_reader to the SprocUser, it works...but that is not going to fly long term. I have 40 or so BOs in this project and all of the rest work fine.