Lost data link to viewer

I have found that by issuing a single dataAvailable "Different" to the sdo after filtering, the viewer now refreshes when choosing a different browser row.

There are no known issue that can explain the problem you are seeing.

After filtering the first record is populate to the browse and view, but if I chose another row in the browse it does not refresh the viewer. If I add navigation to the toolbar and select next both the viewer and browse is refreshed and from then on choosing a browse row refreshes the viewer.

This indicates that there is a problem with the browser's communication with the SDO. The fact that it works with navigation means that it works when the SDO is in control and that the link from the SDO to the viewer works as expected.

I have found that by issuing a single dataAvailable "Different" to the sdo after filtering, the viewer now refreshes when choosing a different browser row.

I believe this is the same as a call to openQuery and a rather expensive workaround, but it is an interesting test. Whatever happens as a result of this should have happened when the filter was applied. Further debugging should thus probably focus on what goes wrong during the "filtering". The described problem would happen if the browser doesn't receive dataAvailable or for some other reason doesn't set the RowIdent, which is used by the browse to see if it needs to publish the change to the SDO.

If this really is a regression bug in adm2 then it will be fixed. I suspect there is some other explanation, but I think you are better off contacting Support in any case. There is enough information to understand the problem you are seeing, but there is not enough information to guess what causes this.

It is for example unclear what you are referring to as "filtering".

Some tests you can do to narrow down the problem:

- Check if the problem is present with the browser on page 0.

- Is the problem present if you call openQuery INSTEAD of applying the filter.

- if yes, then any further drill down is of interest.

- Is any other objects contributing to the problem. Remove all links and objects that you have not mentioned one by one and check if the problem persists.

- And of course; check if you can duplicate this with a simple sports2000 app without any customizations. I would actually try this before anything else, since Support then doesn't need much more info.

The procedure works ok under 10.1A but doesn't under 10.1C01. I fairly sure that I had the procedure running ok under 10.1B i.e. without change.

This procedure was originally created by another, so I'm just picking up the threads.

It uses the filter standard dynamic toolbar, but it just runs our own filter on page 3. Probably by this in initializeObject

subscribe to "StartFilter" in h_dtb-staff.

When the filter button is pressed, it then sets up a query and -

dynamic-function('setQueryWhere':u in h_dstaff,lc-where).

dynamic-function('openQuery':u in h_dstaff).

I found that the viewer receives a dataAvailable 'RESET'. So I added this to the select of page 1 (where the browser is) to get it working.

PUBLISH "dataAvailable":U FROM h_dstaff ('DIFFERENT':U).

I have another rather complicated window with several tab that has no open query and has no filter but is driven by the sdo and sbo links. The problem page has a browse and viewer. Again clicking another browse row does not refresh the viewer. The first procedure I described has a dynamic browse and this one has a browse procedure. I don't know if a RESET is received but to solve the issue I publish a dataAvailable Different on choose of a tab.

I have several other procedures with browsers and viewers that appear at this stage to work as they should.

I raised the issue with Support last week and they were just trying to reproduce on Sports but I personally think they will work ok as I have others that work ok. I have removed other objects but didn't want to change pages as the filter is on page 3 anyway. I did find that if I added navigation to the toolbar a clicked on the next button that things started to work ok, but you had to click a navigation button first.

I suspect you are right that Support won't be able to duplicate this in a default environment. The additional info you provide here does not reveal anything out of the ordinary either.

The openQuery call in the filter should be published to the browser and viewer.

Your workaround is ok, as long as it is published FROM the sdo, although the general advice in late v9 and v10 is to publish dataAvailable('RESET'). This ensures that child SDOs only are reopened if the parent does not match, while a browser's dataAvailable will do a bit more since the record might be the same and the browse widget might need to be refreshed. A 'DIFFERENT' tells the browser that the data change is so "big" that the widget already is refreshed.

If you want this resolved you need to continue to work with Support and provide the info (or zip files) they need to duplicate the issue.

The following info on the behavior could provide valuable info:

- What does getRowident of the browse return right after the filter is applied? (without the workaround of course)

- What does getObjectType of the browse return?

- is DataAvailable called in the browse when the filter is applied?

- Does it work with the browse on page 0?

getRowident shows ? and the type on the one I tried was a smartDataBrowser but this one is actually dynamic while the other procedure where I have the issue is not dynamic. On the dynamic one that I tried I couldn't trap dataAvailable.

I moved the browse to page 0 with no change in the result and getRowident was still ?.

When it was on page 1 I tested getRowident after issuing dataAvailable from the sdo and it had 2 rowid values.

This explains the behavior. The user's value-change calls OnValueChanged, which checks IsOkToFetch() to decide whether to synchronize the SDO. IsOkToFetch() compares the first entry in RowIdent with the current record's physical rowid and returns false if they already match or the RowIdent is ?. This check is the key to resolve the fact that the browser can drive the SDO and the SDO can drive the browser. The false condition is basically preventing an endless loop or at least an unnecessary AppServer hit.

This is older behavior than 10.1A (except if your browser is a QueryObject. I'm not going to explain this as it is very unlikely in particular with a dynamic browser, but it still needs to be eliminated as a cause - someone could have set the property by accident, so verify that the browser's getQueryObject returns false).

The RowIdent should never be ? in a browser that is linked to a data-source with data and the browser must receive dataAvailable to work with its data-source. If it doesn't then this is the problem that need to be further investigated. The fact that it also is a problem on page 0 might indicate that the link doesn't exist at this moment, but there are many other possible scenarios.

Message was edited:

rowident should never be ?

Havard Danielsen

The browser's getQueryObject does return false.

As expected.

On the dynamic one that I tried I couldn't trap dataAvailable.

I misread this. I now realize that you probably refer to the fact that you cannot override this event in a dynamic browser.

Given the fact that you can kick the browser back in shape by a publish dataAvailable from the SDO, it is also rather unlikely that the browser does not receive this. (unless the filter actually turns links on and off, but the fact that it worked in 10.1A hints at something more subtle)

One thing you could test before you zip this up and pass it to Support is to override setRowident and look at the stack trace and values. Check if it is ever set to something other than unknown before the filtering is done. Check if it is called any/many times during the apply of the filter and most importantly, try to find the case when it is being passed ?. I don't think this is enough to resolve the case, but it could.

I added an override to the viewer for setRowident. It displayed correctly immediately after the filter, but if I didn't apply dataAvailable 'different' then I received no further response. If I did apply dataAvailable then setRowident displayed correctly.

That's all normal and expected behavior.

It almost hints that the getRowIdent does weird stuff, but the default adm2 getRowIdent should not do anything with SDOs, only SBOs. (There have been cases where Dynamics Container Builder did not refresh all info when changing an existing data link from an SBO to an SDO)

In any case, we are not going to resolve this here on PSDN. I strongly suggest you get the code to Support, so we can get to the bottom of this.

The rule of thumb is that the harder the bug is to find the easier it is to fix...

That's all normal and expected behavior.

It almost hints that the getRowIdent does weird stuff, but the default adm2 getRowIdent should not do anything with SDOs, only SBOs. (There have been cases where Dynamics Container Builder did not refresh all info when changing an existing data link from an SBO to an SDO)

In any case, we are not going to resolve this here on PSDN. I strongly suggest you get the code to Support, so we can get to the bottom of this.

The rule of thumb is that the harder the bug is to find the easier it is to fix...