UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V < 1 2  (Go to first unread post)
   Reply to this topicStart new topic
> Field Names And Special Characters, 2013 and O365    
 
   
AlanAnderson
post May 11 2015, 03:33 AM
Post#21



Posts: 1,307
Joined: 19-October 12
From: Blantyre, Malawi


Hi All,

I would like to get back to the issue of subdata sheets.

Whereas Jack makes a good point regarding Access' penchant for selecting what it thinks is the best link, I am wondering if there is still a place for its use.

I am thinking specifically of the General Ledger.

I think it could possibly provide an excellent "drill down" facility pretty much automatically.

ie a Datasheet showing the expense accounts, if one presses the + sign could it not show you all the transactions involved. The pressing the + for a particular transaction it could display those details.

I'm not sue as regards the performance impact, but seeing as the Accounts table is pretty small which would relate to a quite substantial transactions table I don't know how serious this is.

If anyone has any experiences of creating Drill downs I would love to hear from them.

Regards

Alan
Go to the top of the page
 
jleach
post May 11 2015, 05:14 AM
Post#22


UtterAccess Editor
Posts: 9,807
Joined: 7-December 09
From: Staten Island, NY, USA


The problem isn't only performance (though I have no personal experience in sds performance... never really used them), but more in the fact that we have no control over which child table it will display. If you have two child tables that are on separate relationships, there's no way to be sure which child the subdatasheet is going to show, AFIAK. Maybe it's the first relationship created, maybe the last, maybe something to do with how the objects are loaded as the project starts... no clue, though I suppose we could do some testing to try and find out (although in the case of testing for "normal behavior", I'd view it much like running multiple event procedures (eg, via class with WithEvents): the application trends towards firing even procedures in the order applied, but there's no formal documentation on it and as such we consider it safer to not assume that it will always act that way - that's the same stance I'd take with whatever results came from testing subdatasheet behavior).

If you only had one child (and would only ever have one child) for a given table, maybe that'd be ok, though I wouldn't bank on restricting my schema like that to get a UI feature out of it.

I tend to think you could use a treeview instead to get drilldown capability, or perhaps some sort of embedded html/javascript utility. A much bigger pain to set up for sure, but much more reliable also.

Or, maybe I'm missing something and making a big deal out of what isn't that big a deal... perhaps there *is* some way to specify (or some documentation stating the behavior) that I'm not aware. That'd be cool.

Cheers,
Go to the top of the page
 
AlanAnderson
post May 11 2015, 06:55 AM
Post#23



Posts: 1,307
Joined: 19-October 12
From: Blantyre, Malawi


Hi Jack,

Thanks for your input.

I must say the reliability issue does worry me.

I will experiment some and see if it can be forced to use the correct child.

If in doubt I will follow your recommendation and forget it (Pity though)

Thanks again

Alan
Go to the top of the page
 
2 Pages V < 1 2


Custom Search
RSSSearch   Top   Lo-Fi    13th December 2017 - 05:27 PM