Creating Named Browses: Question

[SNusa]

I cannot remember the criteria for choosing between the following (when working with .dbf's):
I do know that you can "build a Named browse" two different ways and have built them both ways for different "applications."
Usually the simplest way is the best way (to just use the child table and not the set), but not always.....

(I recall that each method below has benefits & limitations. I just can't remember them exactly)

1. Creating the named browse based ONLY on the child table.
2. Creating the named browse based on THE ENTIRE SET.

If I recall, one of the reasons had SOMETHING to do with calculating subtotals and grand totals.
But there were others too (beyond just wanting to display parent data in the browse!)
(Browse properties considerations? xBasic considerations? Filtering/sorting? Performance?) ~ I'm drawing a blank here.

Note: This question applies with regards to browses that will be used within forms on the "classic desktop." (Forms based on sets with parent/child relationships.)

[G Gabriel]

Re: Creating Named Browses: Question

Better or worse depends on the context.
That said, what do you mean by building a browse based on a set?
Is that a 1:M? or 1:1 set?

[SNusa]

Re: Creating Named Browses: Question

Better or worse depends on the context.
That said, what do you mean by building a browse based on a set?
Is that a 1:M? or 1:1 set?

Hi G;

One to many set (like a "run of the mill" invoice with a "named browse" displaying transaction details.) ~ Where the browse can be created from just the details table, or the entire (same) set that the form is based on. I don't use AS, so that was not a consideration. (I do recall running into an issue that necessitated designing the browse on the entire set, regardless of whether any of the parent record data was going to be displayed/edited...

I had done some rather in-depth "experimenting" on this last winter. But when I ran into browse rendering/display problems associated with the "parent record only" browse setting... I must have forgot to document my own findings. (I hate when that happens.)

[Ray in Capetown]

Re: Creating Named Browses: Question

i have always traditionally built an embedded browse on form.
In a recent new project I decided to use a named browse, having more cosmetic advantages and re-usability, I thought.
Half-way through had to redesign as there were (as I recall) control over certain events issues. Gave up trying.
It was only a couple of weeks back but I've already lost the sequence in memory as this is part of a complex fiduciary system. Made a mental note to create embedded in future.

[G Gabriel]

Re: Creating Named Browses: Question

Robert:
I am not sure what to make of this?
You want to design a browse based on a 1:M set?
First: Yes you can. But that would be most definitely the most ridiculous thing you could do as it defeats the whole concept of relational database.
A browse based on a 1:M set will display repeated records for the parent for as many child records there is for that parent record. I don't think you want that, do you?
Second: With that in mind, I read your following sentence and you say "parent record only", and you lost me again.
Not sure what to make of that?
If you mean, you want to display only the parent but not the child(ren), that goes in contradiction to what a browse based on a 1:M set will do, which I explained earlier.
If you want to display parent record only, you would base the browse on the parent table, not the set.
If you mean in a case where there is a parent but no children, that should display as one record in that browse.
I am not sure what is it you are trying to do and why?

[SNusa]

Re: Creating Named Browses: Question

Robert:
I am not sure what to make of this?
You want to design a browse based on a 1:M set?
First: Yes you can. But that would be most definitely the most ridiculous thing you could do as it defeats the whole concept of relational database.
A browse based on a 1:M set will display repeated records for the parent for as many child records there is for that parent record. I don't think you want that, do you?
Second: With that in mind, I read your following sentence and you say "parent record only", and you lost me again.
Not sure what to make of that?
If you mean, you want to display only the parent but not the child(ren), that goes in contradiction to what a browse based on a 1:M set will do, which I explained earlier.
If you want to display parent record only, you would base the browse on the parent table, not the set.
If you mean in a case where there is a parent but no children, that should display as one record in that browse.
I am not sure what is it you are trying to do and why?

I've been working on this today. And here's a link (video cast) highlighting the display issues I have encountered regarding embedding "Top Level Set Based Saved Browses" (Named Browses saved in the browse tab of the control panel) into forms, while trying to "understand" their purpose. http://screencast.com/t/BERqziQ6xa
IMPORTANT: In the video, the first field "Keyfob" is from the "Parent table" That's the only reason it's always showing in both browses. (The rest of the data is from the child table)

I didn't focus on the navigation issues on the video. Even so, several times, near the end of the video I was clicking on the fields in the left hand pane. The browse/form was not responding as expected.)

From a development "when to use" standpoint, I really want to know the significance of "top level set based saved browses", and also what the purpose of the "Parent Records Only" browse property, since the property setting seems to either be completely broken, or have no value due to the display issues. (Actually, the same can be said about the option to use "top leve set based saved browses." (No value? Useless? Or just "broken?")

Also, see the screen captures near bottom showing both the selection screen, and the warning screen.

I suspect the reason Alpha gives you the ability to choose a "Top Level Set Based Saved Browse" (see screen captures) is to: Facilitate the possibility that one might want to display all "children" records (in a browse on a form) regardless of which parent record is selected from the parent table. I think my question may come down to the "parent record only" setting (in the "Named Browse" property settings) essentially being "useless." (Due to both/either browse rendering & scrolling issues.)

The following scenario only uses a form & "Named Browse", both based on a set containing ONLY a single link (parent/child relationship.) ~ like a basic invoice with transaction & transaction details
When you do this, no matter what you try, you will have problems (using a "Named Browse" based on the entire set) in a form if that "Named Browse" displays any of the fields from the detail/child table....

Parent Records Only set to NO:
You will see all the records, BUT: Whenever you click on a detail line item, the field you click on changes to display the value of the "first occurance" of the value in the child table. (ghosting)
For example: As you click on each individual detail item record in the browse (invoice items), one by one the price, description etc. will change until all eventually end up reflecting the first occurnace data values.
(Data in the fields change before your very eyes as you click on the rows until all rows show the same data.)

Parent Records Only set to YES:
You will see only one instance of all the all the records in the browse, BUT: Only the parent table fields populate with data. (All the child fields are empty on the browse, until you click on them. And when you do, once again you get the "first occurance" value to display like above.

Note: A "standalone" ("Named Browse") can ONLY be selected for placement on a form only when the browse was built based on either the Parent or Grandchild (not for the middle/"child table") as being the master table of the "Named Browse." ~ What I'm trying to explain with this note is: If you have form based on a set that contains parent/child/grandchild.) In this instance, you are not given the option to "embed" a browse which was based on ONLY the "middle" child/grandchild...

RELATED ISSUES:
No matter what settings you try in scroll bar settings, you cannot get the display to work properly.....
On large "child data sets" (with certain scroll settings) you sometimes can't scroll all the way down the list. (or back up for that matter)
And while clicking on records (with the mouse) may work at first.... If you try to go back and select previously viewed records, the browse may not respond.
The little arrows on the scroll bar don't work at all. However..... You may be able to click above and below the drag area to move up and down through the records.
You can't always navigate the records properly clicking above/below either. (Although using <ctrl><end> and <ctrl><home> seem to always work, this problem can make it impossible to see the records in-between.)
Arrow keys (keyboard) are virtually useless. Highlight a field and try to go up/down. (You can't.)
Finally, in some instances I found that although you can "sort of" navigate up and down, you may never be able to view the last records.
(When this problem occurs, the only way to see "more" records is to open/view the "Named Browse" outside the form. Here scroll won't work. But if you expand the browse vertically (something you can't do with it embedded in a form), you may be able to get to/see the records at the bottom.

Notes regarding embedding a "Top Level Set Based Saved Browse":
There's a warning that it needs to be set or you will see duplicate data. (see warning screen capture attached which displays when the browse is inserted into a form.)
Regardless of the display issues, when you click on a record, the form does respond by going to that record.
I also remember that there were some issues I encountered regarding calculating totals too. (along with workarounds)
These "issues" were reported last winter. I don't know whether any of them were addressed in v.12 (Haven't checked yet.)
According to Cian, he had indicated he intended to do what he could, but they enhancing SQL performance at the time (as I recall) and that he would follow up when "time permitted."
I was assured by sales (during subscription renewal last week) that although bug "fixes" were delayed for a while due to v.12: Nothing had "slipped through the cracks" and bug reports had been monitored & were being addressed in the new version. (He implied that this included "classic desktop" bugs.) Fingers crossed.....

If you look at any of the help files (old or new), this is all "help" I can find:
Parent records only (display only the top level table in a set).
:formname.browsename.outline_level as N

Snap 2014-01-04 at 16.01.45.pngSnap 2014-01-04 at 11.46.07.png

[SNusa]

Re: Creating Named Browses: Question

As I experiment with the "Parent Record Only Setting" with "Set Based Named Browses, I've just uncovered another VERY SIGNIFICANT & WORRISOME BUG!

This one is a bit unnerving to say the least! ~ Alpha v.11 is "becoming confused" with short names! I haven't checked v.12 yet, but I have a bad feeling about this.....
Incidentally, with the exception of this "most recent find", the other browse related bugs were thoroughly documented & reported last winter/early spring.

While you're watching the following video, take notice of the names of the two different browses that are initially opened for viewing.
(4 character and 5 character names, both short, both close, but different - at first anyways.

I usually use longer more descriptive names, but these short names were chosen solely for testing purposes.
Not that it matters, but _= temporary, b=Browse, K=Keyfob table, P=Points table, and "b" signified a similar version. ( aka: _bKP and _bKPb )

FYI: These are the same browses used in my previous post/jing screencast. ~ Now they're running alone, side by side, outside a form.)
Nothing fancy, no corruption, indexes are fine, and no reason for this behavior is apparent. I just made up all these examples (including the sets) from .dbf table data earlier today.

http://screencast.com/t/8Oi2XDJUrBw

Both browses are identical with the exception that the one on the right has the "Parent Records Only" property set with a check-mark in the box.
The first column on each of these two similar browses are both indexed, primary keys & are "in" the parent table.

Outside a form (unlike when placed within a form), the browse on the left does not exhibit any strange "ghosting" where the values are changed. ~ Seems 100% OK if used this way.
The browse on the right still exhibits very strange behavior navigating from record to record.
And the only way the make child record details appear is by dragging the scroll-bar and "dropping" it near the center of the browse.
(Clicking above and below the drag region just navigates, but nothing shows from the child table.)

Now here's where things get really strange!!!!!!
After exhibiting the strange behavior of the browse on the right, I selected the browse at the left and switched it into "edit mode" using the button in the default a5 toolbar.
Immediately, this browse took on the appearance of the other browse, and the name in the window bar changed.
~Somehow the originally opened browse gets replaced with a second instance of the OTHER browse at the right!

Notes:
After this happens, I checked the XBE. Sure enough, there were multiple instances of the same browse open. (and the other one that should have been still "open" had disappeared completely) So now it appears that short names (browse objects 4 and 5 characters in length) are being "mixed up" by a5. (at least during development & testing) The first time this happened, I thought I had somehow made a mistake, but that was not the case. (I can reproduce this behavior over and over again.) ~ Also, I can swap browses and end up with two instances of either of them, depending upon which sequence I use. FYI: One thing that seems to trigger this "internal a5 confusion" is: Demonstrating the odd behavior of the browse that has "Parent Records Only" set. (I doubt it's the only thing though.) Also, I'm using the most recent "nightly build" of a5.

Snap 2014-01-04 at 23.40.04.pngSnap 2014-01-04 at 23.44.29.png
Images above were captured while "reversing the process" where I chose the other form for editing mode.
Two different browses were open, until I simply switched one of them from view to edit mode.....

Somehow, this has turned into (another) "all day project." ~ AAaarrrgggghhhh!!!!!)"

[G Gabriel]

Re: Creating Named Browses: Question

Robert:
I wish I have the time to delve into this, unfortunately I don't, especially so since I am not a fan of browses, embedded or otherwise. With very few exceptions and from a logical point of view, they do not make a whole lot of sense to me.
best of luck.

P.S.
One of my Message board rules, if I have to scroll down the screen to read a post, it's time to move on no matter how interesting or how important the subject might be.
I know you want to be as through and as comprehensive as you can be, but on the message board it is better to provide the salient points and if someone asks for more info, that would be the time to provide more. But with this much information upfront, I promise you, you will loose a lot of audience. I am the first one to run to the exit due to the time crunch.

[SNusa]

Re: Creating Named Browses: Question

Thanks for the suggestion/heads up... But I still hope you took a look at the videos. This one (below) in particular. (This may be a larger "still present broken pointer issue" effecting all manipulated data withing the a5 (and AA) GUI! ~ Opening 2 browses (different names) and then switching one into edit mode results in two "instances" of the same browse being shown (and reported) in the XBE.

A5 v.11. (and possibly v.12) is/are undeniably loosing track of it's/their own objects during the application development stage!
(I can make this occur repeatedly without trying. ~ I suspect pointer references to objects are becoming "internally crossed.")

VIDEO: http://screencast.com/t/8Oi2XDJUrBw (start with opening 2 different browses, and end up with two instances of the same one at the end ~ after changing one from view to edit mode)

I know I tend to get "wordy", but without the supporting details documented, it's easy to get confused. (And harder to "go back to at a later date" and/or diagnose / fix.) ~ That's what happened to me last year (and the original reason for starting this thread.) ~ I didn't document the particulars, and thus couldn't remember them.....

For years, everyone has concerned themselves with index length bugs, object name restrictions, table field name problems etc... I've never heard of this problem occurring with object naming conventions this short! (4 characters)

Of possible significance: I may have originally duplicated the first browse (before making the single change to the "Parent Record Only' setting.) ~ I don't think so, but I'm not certain.
Irrespective, this doesn't matter (except for diagnosing & correcting the underlying BUG.) ~ Although I suspect "object duplication" in the CP is a commonly used feature.

[G Gabriel]

Re: Creating Named Browses: Question

I will..as soon as I am finished with my Christmas list.

[Peter.Greulich]

Re: Creating Named Browses: Question

I will..as soon as I am finished with my Christmas list.

What's Christmas?

[G Gabriel]

Re: Creating Named Browses: Question

Last one.

[SNusa]

Re: Creating Named Browses: Question

That's the thing that concerns me with regards to the future of this product...... Two years ago, issues like this were "taken seriously" and "dealt with" accordingly.
But recently, nobody seems to really care, not even the Alpha user base. Not anymore at least..... If we (as a group) give the appearance that "we don't care", what can we expect the outcome to be?

Just think about the implications here..... ~ I'm not being critical here of anyone's responses. (I'm just trying to look at things "objectively" as I decide where to go from here.)

[Peter.Greulich]

Re: Creating Named Browses: Question

That's the thing that concerns me with regards to the future of this product...... Two years ago, issues like this were "taken seriously" and "dealt with" accordingly.
But recently, nobody seems to really care, not even the Alpha user base. Not anymore at least..... If we (as a group) give the appearance that "we don't care", what can we expect the outcome to be?

Robert,

That's what ya call an unfounded statement. People care now as much as they did previously. I watched your video. Not sure what to make of it. If others can duplicate it, it's a bug. But like you say it probably only occurs in development mode. I've always had to reboot Alpha in development mode to clear memory bugs as long as I can remember. Not a big deal for me. My real-life desktop apps run and run and run - and when I look at some of my convoluted legacy code I shriek in horror, but it still works nonetheless and I never have clients calling me complaining it's not working. If the apparent bug you discovered doesn't happen in actual end-user environment, I don't see the concern. If it does affect end-users and there is no simple workaround, then it might be a problem. But truthfully, although I have my issues with Alpha, there's a lot of perfectly legitimate workarounds. So, all I can say is, in the ideal world it should be fixed, but if the problem doesn't affect you in the real world then I fail to see the drama.

[G Gabriel]

Re: Creating Named Browses: Question

nobody seems to really care

Robert:
It is not that I do not care or do not take it seriously, I do. But you don't seem to understand that this is not what I do for living. There is not enough hours in the day to do what I need done just to take care of my business. I glance at the board, fly in and fly out. Any time I see a page long post, I run away, period.
You expect me to read your editorials and watch a movie!
I am sorry, I would love to help, but I can't spend hours on the board.
You have to make your questions precise and to the point. One question at a time. Then another and so on. You will get much more help that way.
That's just my advice for what's worth.