Problems with SharedDataTableKey


Author
Message
Richard Keller
Richard Keller
StrataFrame User (174 reputation)StrataFrame User (174 reputation)StrataFrame User (174 reputation)StrataFrame User (174 reputation)StrataFrame User (174 reputation)StrataFrame User (174 reputation)StrataFrame User (174 reputation)StrataFrame User (174 reputation)StrataFrame User (174 reputation)
Group: Forum Members
Posts: 84, Visits: 324
I'm pretty sure that I have isolated a problem with the shared data table key and I have a secondary problem on how the filter is handled.   I'll see if I can explain.   If you create a BO and specify a SDTK( Shared Data table Key ) then the first time that the BO is instantiated and filled everything is fine.   But for some reason if there is a Object or Form that Dispose of the last instance of that class then the SDTK is now a bug and upon the first new instance of the Same BO type then the DataRow Index will be all messed up.   It looks like the Finalize of the BO does not removed the SDTK from it's collection for SDTK keys.   I'm pretty sure that this bug is the reason for a couple of the SDTK posts.

Second problem with SDTK.  Filters.   If you are using 2 BO that are bound with a SDTK and you filter one of them the second is filtered.  Is there a reason for this?  For my thought process is for lookups that rarely get update or automatically notified if DB changes then having a BO with a SDTK would work well and does.  Up until one of those BO's are filtered for some reason and then All of the BO's are filtered.   This obviously messes up a bunch of things.  

Any ideas?

Richard

Reply
Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
I'm pretty sure that this bug is the reason for a couple of the SDTK posts.

The best thing I could recommend here is to create a small sample that reproduces the issue you are describing versus going back and forth and we will take a look at it.

Second problem with SDTK.  Filters.   If you are using 2 BO that are bound with a SDTK and you filter one of them the second is filtered.  Is there a reason for this? 

This is correct and by design.  From the sound of it you may be overusing the shared data table.  The shared data table is the internal data of the BO...this includes the DefaultView attached to that shared data table which is shared as well.  Secondly, and I know that you have probably read this on other posts, but if you find yourself using a filter a lot, then you probably should be restructuring some of your code because this generally indicates that you are bringing back more data to the client side that may be necessary.  Just a recommendation.  This is something that we will cover in class and is something that I have been having a lot of conversations about lately.  Filters are great when using under cetain conditions...and in moderation.  But if this is a common design of your application you are in for a lot of frustrations and the larger the application grows (or the more data added from a larger client) the more problems you will encounter.

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