Summary record displays differently depending on whether data sheet is open or closed when procedure is run


#1

In amongst a larger procedure I have this code snippet:

ifselect CB ≠ "DLCSI"
    field OnSite total
                            field OffSite total
                            TotOnSiteBody = pattern(OnSite,"#.##")
    removesummaries 7
endif

ifselect CB = "DLCSI"
    field OnSite total        
                            field OffSite total
endif

ifselect CB = "DLCSI"
    field OnSite total        
endif

You can see that I’m totalling one data selection, removing the summary record and then totalling another data selection. If the data sheet is not open when I run the code, the summary record can be still attached to the first selection and not visible in the second selection, depending on whether or not I comment out one or more of the three indented lines of code.

Could somebody please see if they can replicate any of this? There doesn’t seem to be a pattern to it and I’ve spent so long looking for one that my head hurts. Everything seems to work well if the data sheet is open.


#2

No replies to this - presumably because everybody thinks it’s a crazy question.

In response to that, I’ve replicated it in a new, simple data base available at:

I’d really like somebody to download that and run Procedure_A either from the menu or by clicking the Run button in the procedure window. Don’t open the data sheet. Sometimes it works as it should, in which case quit Panorama X and try again. It is quite erratic.

I realise that I can overcome the problem by inserting a selectall statement before the removesummaries statement but my point is that this is aberrant behaviour whose cause should be tracked down.


#3

Michael - I downloaded your test file and followed your instructions. You did not say what erratic behavior to look for in the test file but I observed that sometimes the summary record would be present with totals for ListPrice and Dollars and sometimes the summary record would not be present.

Before closing the data base, I manually deleted the summary record in the data sheet and manually selected all records. Upon opening the file again and running the procedure, sometimes the summary record would be there with totals and sometimes not.

I commented various lines of code out but did not find a consistent pattern.

One note about using operators with text:

I don’t understand why
ifselect Title > “G”
selects the two titles that begin with “G” along with those titles greater than “G”. I would think that the two titles beginning with “G” would be excluded.


#4

The same as I initially described:

… and that’s what you found also. Thank you for rescuing my sanity. Now all Jim has to do is work out why it’s happening.

Because “Getting” and “GIF”, etc. are greater than just the letter G.


#5

Hello Michael, I confess that I do not understand exactly what you are seeing, but I do get erratic behavior. When I run the code in your test database, I would expect to end up with the data sheet showing and a selection of records and the total for two fields. The first selection is gone. But I do not always get totals for both fields. One totals but the other does not.
On other topics, I wondered why you use the ifselect/endif combination. You are not using an “else” statement to test for an empty selection, so why use ifselect?
Assuming I wanted the totals for some field for a selected group of records, I would just use the aggregate function. For example, (and I think you know this) you can directly get the total of the ListPrice for Titles < G with this:

aggregate({ListPrice},"+",{Title < "G"})

I never want to access the data sheet in a finished database and I try to avoid ever making a selection of data. I just leave it alone. But in part that is because the databases I have developed are meant for the least proficient computer user and I never want the user accessing a data sheet.

Good luck to whomever tries to solve this. (I thought we would have heard from Dave T. already!)


#6

I get the same results as Tom. If I run the whole thing I end up with the second set of records and a summary in which the List Price is Totalled, but not the Dollars. If I run just either half of the code, I get the appropriate set of records and both fields totalled. I can’t say I understand what you’re trying to end up with, though.

Tom Cooper wrote:


#7

Sorry, I thought I’d made that clear in my initial post. Basically, when I do a total of selected records, the summary record appears in the unselected group of records and is neither visible nor directly accessible. And sometimes it doesn’t really total anyway, as Bill Conable found.

I did use ifselect, elseif, endif in my original code - I thought that the aberrant behaviour may have been due to corruption in that database so I created a new database and worked at writing the simplest possible code which still displayed the bug. This way (I thought) people can easily see what should happen and compare it with what actually happens - it’s not a real-world project, just a demonstration. Somehow I seem to have confused you guys even so.

Question for Jim - can you see that this is a bug?


#8

FWIW: I downloaded the file today and tested it with the just released Pan X build 2790. The procedure works as expected. I am not seeing any irregularities.


#9

This sounds like very good news Kurt - I’ll try it tomorrow.


#10

I cannot confirm the findings of KJM. I tested Michael’s file today with Pan X build 2790 and found the same behavior I reported above. Specifically, when the Data Sheet is closed and the procedure is run, sometimes the summary record is present with totals and sometimes it is absent. When the Data Sheet is open and the procedure is run, the summary record is present with totals.


#11

I repeated my test in the afternoon, and now I am seeing some of the described inconsistencies.
Another symptom, that was not mentioned before: Even when the both totals of the second selection are displayed, the record count may be wrong (not counting the summary record as visible).