I was always under the impression that the DCOUNT function should return 0 when the string in question is null, to properly reflect the number of delimited values in a string. Here, using OI 4.1.3, it is returning 1.

Is this the planned behaviour or a bug?

I'm curious of the answer to this. The Pick that I used to use had a dcount function that was essentially identical to count(x,delim) + (x ne ). Revg had a dcount function that was identical to count. Perhaps this is why it was removed from Arev. Does it have the Pick functionality in OI? If you share code with Arev, I suggest not using this function because it doesn't exist. </QUOTE> —- === At 07 AUG 2003 05:05AM D Bielby wrote: === <QUOTE>Hi Victor, I'm from a Pick background, which is why I was thrown when the results differed from what I would expect. The online help is also ambiguous - the top section makes no specific mention of the case when the source string is null, but the example code implies that zero will be returned in this case, as in Pick. I wasn't aware the function existed in RevG as I've never used it, but do remember the painstaking task we had to change all the dcounts in our code when we converted our Pick system to Arev! </QUOTE> —- === At 07 AUG 2003 07:23AM Mike Ruane wrote: === <QUOTE>What string are you checking, and what result do you expect? </QUOTE> —- === At 07 AUG 2003 10:13AM Richard Wilson wrote: === <QUOTE>I just tested with my version of G2 and DCOUNT is not a function 'XX' Line 3 B105 'DCOUNT' has not been dimensioned or declared as a function. you must have had your own homegrown function. One of many reasons I never used dcount when it was available, you never know where your software is going to be installed 20+ years later </QUOTE> —- === At 07 AUG 2003 10:24AM Victor Engel wrote: === <QUOTE>It's documented in Revelation Revealed. Of course, the documentation says, "See COUNT". Also, release notes for some OI version says DCOUNT is reintroduced. I jumped to a conclusion based upon this wording. On the other hand, I do have a memory of coding using DCOUNT and running into this issue, so if there was no DCOUNT function, I'm puzzled where the memory comes from. Either way, DCOUNT didn't work as expected so was essentially useless. </QUOTE> —- === At 07 AUG 2003 11:01AM jay o rappaport wrote: === <QUOTE>This is from the ONLINE help for DCOUNT on oi4.1.3. If would appear that there is a conflict in how it has been impletemented since the first part states "Counts the number of occurrences of a substring in a string, returning 1 if the there are NO occurrences of the substring in the string." while the detail description/specs state "Identifies the string to search for in source_string. search_string may be a literal string, expression, constant, or variable. If search_string DOES NOT appear in source_string, OR if search_string is null, a 0 (zero) will be returned." Since Dcount can be used to count the occurance of any string "They actually have more general purpose use, because the search string can be any string used as a delimiter, even multiple character strings." if SHOULD return 0 if the string is null - meaning there is NO OCCURANCE of the string. Returning 1 when the string doesn't occur, means you could endup in a fatal loop where one statement says a string occurs, and then when you try to split the field on that string you never find it or execute code that has no value and results in some program failure. The need to add 1 to the result of count is that the original PICK implemention was to count system delimiters. If you where counting attibutes/fields, the need arose to add 1 since there was no FM at the end of the record. A record of 10 attributes only had 9 FM's, the end of the record actually had a different terminator a RM. This resulted in always haveing to check for null and adjust the count returned. Count returned the ACTUAL count of the occurance of the delimiter and Dcount should do the same. It would seem that both Count and Dcount could be made smarter by recognizing that the search string IS a system delimiter and then adjust the result by 1 IF the string is not null. While this could actually return the WRONG answer, it would not be a fatal one since if you are looking at a dynamic array, reference x or x when the field is not multi-valued whould still return the correct answer since those are the same as x. </QUOTE> —- === At 07 AUG 2003 11:24AM D Bielby wrote: === <QUOTE>Mike, This is the simple test I used: DECLARE FUNCTION DCOUNT tst=' x=DCOUNT(tst, @VM) return x From my experience of Pick I expected a zero to be returned, but got 1. I always read this function to mean "delimited-count", i.e. a count of the number of multivalued fields in a string, which should be zero for a null string. From a coding perspective, if all the function does is perform a normal count and add 1 to the result without handling the case of a null string, it seems pointless to go to the extra effort of declaring the function to use it - it's as easy to just use Count and add 1. </QUOTE> —- === At 07 AUG 2003 12:51PM Richard Hunt wrote: === <QUOTE>Geeesss… Only Revelation could take a function called "DCOUNT", that has been around for about 15 years (Pick wise), and confuse it. Clearly in my mind the "DCOUNT" function is a direct copy of the statement… COUNTER=COUNT(STRING,DELIMITER) + (STRING NE )

And it just so happens that it works that way in "Pick like" applications.

Just a note… something like this does cause a developer to spend hours trying to figure out why some software routine is not working properly. It would be appropiate if the help topic on the item clearly explain the item's intentions and proceedure.

Arev renamed it FieldCount, still exists undocumented in OI

Try Fieldcount instead of Dcount.

If you like it, copy sysobj $fieldcount over $dcount till we fix it.

Bob

What version(s) of Arev have fieldcount? I don't see it.

I've got it in 3.1

Arev 3.1, that is

Dont try

DECLARE FUNCTION FIELDCOUNT

FOR V=FIELDCOUNT(X,@VM) TO 1 STEP -1

Cos it doesnt work, but does this way around:

FOR V=1 TO FIELDCOUNT(X,@VM)

View this thread on the forum...