StrataFrame Forum » StrataFrame Application Framework - V1 » Issues » Problems with SharedDataTableKey

Problems with SharedDataTableKey

Richard Keller — Fri, 14 Mar 2008 14:25:23 GMT

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

RE: Problems with SharedDataTableKey

Trent L. Taylor — Fri, 14 Mar 2008 14:25:23 GMT

Gotcha. Sounds good.

I agree with your methodology, but like you mentioned towards the end of your last post, I would probably create a static or shared class that does this for me and then allows me to pass over a BO for population. You can definitely use the shared data table in this scenario as well.

RE: Problems with SharedDataTableKey

Richard Keller — Fri, 14 Mar 2008 14:03:58 GMT

I'll recreate and post a sample for the bug.

I'm full aware of the use of filters and when to use. All of my applications are in the millions of records and thousands of transactions an hour. For large datasets and heavy transacted tables it would be almost always be primary key usage only.

I'm using the filters on Dual Lookup Tables and Settings that are mostly static. For an example I have Shipper BO and the children ShipperMethods and ShipperWarehouse. So when you select a Shipper you filter the results of the ShipperMethods. This is done for drop down display as well as settings. These three BO's are used throughout the Shipping Module and contain less the 100 rows total on average. Preferably I simply just wanted to load them once for the entire application instead of loading and reloading all the time. In this type of instance I want to share the data but not the view. I guess I can build a caching system that simply copies data from BO to BO or look into the source and see what it takes to add a IsFilterEnabled Property.

Richard

RE: Problems with SharedDataTableKey

Trent L. Taylor — Fri, 14 Mar 2008 13:11:49 GMT

[quote]I'm pretty sure that this bug is the reason for a couple of the SDTK posts.[/quote]

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.

[quote]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? [/quote]

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.