Dcount not defined (OpenInsight 64-bit)
At 17 JAN 2022 09:48:21PM cmeyer wrote:
Another difference between OI9.4.6 and OI10.1
It appears that in OI10.1 "Dcount" has to be defined as a function where as in OI9.4.6 this is not required.
Is this a bug in OI10.1
Chris
At 17 JAN 2022 11:38PM cmeyer wrote:
Further info.
The problem is not if Dcount needs to be defined but there was an "Undefined variable" vm$.
NoPays = DCount(payids, vm$)
I have since defined vm$ and now OI10.1 runs without going into debug.
This still leads me to ask why it worked in OI9.4.6 and that the compiler does not show a problem. I now have to see where else I have this issue going through more that 2,100 stored procedures
Chris
At 17 JAN 2022 11:44PM Donald Bakke wrote:
Further info.
The problem is not if Dcount needs to be defined but there was an "Undefined variable" vm$.
NoPays = DCount(payids, vm$)
I have since defined vm$ and now OI10.1 runs without going into debug.
This still leads me to ask why it worked in OI9.4.6 and that the compiler does not show a problem. I now have to see where else I have this issue going through more that 2,100 stored procedures
Chris
I cannot replicate the problem you are describing. Are you saying the program won't compile or that the program yields a runtime error?
At 18 JAN 2022 12:15AM cmeyer wrote:
In OI10.1 there was a run time error where as in OI9.4.6 runs OK.
I have since looked for other instances and fixed Dcounts in OI9.4.6 with missing variables ready for another migration.
Chris
At 18 JAN 2022 12:24AM Donald Bakke wrote:
In OI10.1 there was a run time error where as in OI9.4.6 runs OK.
I have since looked for other instances and fixed Dcounts in OI9.4.6 with missing variables ready for another migration.
Chris
And I assume the runtime error was a VNAV? Well, I used your exact code in 10.1 and it runs without any runtime errors, just like 9.4. This leads me to believe something else is different in your code or your environment.
At 18 JAN 2022 01:12AM Andrew McAuley wrote:
Are you missing the $insert that defines VM$?
World leaders in all things RevSoft
At 18 JAN 2022 01:12AM Andrew McAuley wrote:
Post removed by author
At 18 JAN 2022 02:10AM cmeyer wrote:
That was the problem.
Just wondering why OI9.4.6 does not complain where as OI10.1 does. That is not to say that OI9.4.6 should work but having to find these issues at OI10.1 run time is a little concerning. It is not practical for me to test every function. Will have to rely on the clients to report any OI10.1 issues once I decide to deploy. I guess that is no different in Revelation relying on the developers to report problems.
Chris
At 18 JAN 2022 02:40AM Donald Bakke wrote:
In OI10.1 there was a run time error where as in OI9.4.6 runs OK.
I have since looked for other instances and fixed Dcounts in OI9.4.6 with missing variables ready for another migration.
Chris
And I assume the runtime error was a VNAV? Well, I used your exact code in 10.1 and it runs without any runtime errors, just like 9.4. This leads me to believe something else is different in your code or your environment.
I need to walk back what I just said. I was convinced that my unassinged variable did not cause a VNAV in 10.1 but upon retesting it does. This is a change from 9.4 where passing in an unassigned variable into DCount it does not produce a VNAV and the variable gets initialized to an empty string.
At 18 JAN 2022 06:04AM Carl Pates wrote:
Jumping in here with some background info:
DCount was added to OI back in 2003'ish as a stored procedure, as devs from other Pick style environments were used to having it. One of the things is does is an unassigned check which, TBH, is not a great idea as you might never notice your program was passing a bad variable and you won't get a correct result - leading to some hard to track down bugs.
DCount performs the same function as the existing FieldCount opcode - so in v10 the compiler emits the FieldCount opcode when it parses DCount, rather than calling a stored procedure. The latter is much slower as a new call frame has to be allocated and removed, the stack updated etc etc, and all it does is call count anyway.
The FieldCount opcode itself will not check for unassigned variables, as it considers that to be the responsibility of the caller - having a null delimiter makes no sense because you can't count the nulls in a string right? :)
At 18 JAN 2022 06:05AM Andrew McAuley wrote:
In fairness, OI10 has helped you dodge a bullet.
Whilst 9.4 won't complain it will ALWAYS return 1 in DCount for an unassigned variable as the delim, so your software has unknowingly been buggy. Thanks to 10 you can now fix that bug ;)
World leaders in all things RevSoft
At 18 JAN 2022 06:18AM Andrew McAuley wrote:
and while we're riffing - why not use @Vm? It's always assigned and as an opcode it's faster than a variable.
World leaders in all things RevSoft
At 18 JAN 2022 10:46AM D Harmacek wrote:
Andrew,
So what is faster, an equate like equ fm$ to \FE\ versus an opcode like @fm?
Dave Harmacek - Harmacek Database Systems - near Boston, MA USA
At 18 JAN 2022 11:02AM Andrew McAuley wrote:
Well assumptions… :O initial testing indicates
The Equ vm$ to \FD\ is quickest
vm = char(253) is second
and @Vm is third, nearly 25% slower than the first. Mind you I had to loop hundreds of millions of times to get this measurable :)
World leaders in all things RevSoft
At 18 JAN 2022 11:05AM D Harmacek wrote:
Mind you I had to loop hundreds of millions of times to get this measurable
and now we call you The Flash
Dave Harmacek - Harmacek Database Systems - near Boston, MA USA
At 18 JAN 2022 11:06AM bshumsky wrote:
Well assumptions… :O initial testing indicates
The Equ vm$ to \FD\ is quickest
vm = char(253) is second
and @Vm is third, nearly 25% slower than the first. Mind you I had to loop hundreds of millions of times to get this measurable :)
World leaders in all things RevSoft
BUT - if you are running this in a UTF8 versus ANSI application, @VM will return different (and correct) info in the different applications, but the EQU and assignment values must be manually changed, right?
SO @VM/@FM/etc. give you the advantage of being correct no matter your environment…
- Bryan Shumsky
At 18 JAN 2022 11:25AM Andrew McAuley wrote:
and for completeness Carl points out that @Vm isn't an opcode - it's a pointer to SYSCOMMON and is copied before use - hence the speed penalty. But also what Bryan said :)
World leaders in all things RevSoft
At 18 JAN 2022 03:55PM Matthew Crozier wrote:
BUT - if you are running this in a UTF8 versus ANSI application, @VM will return different (and correct) info in the different applications, but the EQU and assignment values must be manually changed, right?
SO @VM/@FM/etc. give you the advantage of being correct no matter your environment…
Eh!?? The system delimiters are always the same single byte characters regardless of UTF8 mode, are they not? (Assuming NoOfDelimiters is not less than 6)
My testing in both UTF8 and ANSI modes shows the following are consistent:
@RM == \FF\
@FM == \FE\
@VM == \FD\
@SVM == \FC\
@TM == \FB\
@STM == \FA\
I thought this was by design and critical for the performance of dynamic arrays internally. These single byte characters are guaranteed unique and not to exist within any valid multi-byte UTF8 characters in OpenInsight's implementation.
Cheers, M@
At 19 JAN 2022 05:48AM Andrew McAuley wrote:
Yup - referring back to the seminal work on this subject ;)
World leaders in all things RevSoft
At 19 JAN 2022 05:00PM Matthew Crozier wrote:
Yup - referring back to the seminal work on this subject ;)
Ok, thanks - still a bit confused though ;).
The UTF16 encoding of the system delimiters is only within Presentation Server, and the OI Get_Property, Set_Property(_only), and Exec_Method procedures take care of the translation to/from UTF16 transparently - is that right? If so then when would an OI developer see UTF16 encoding of the system delimiter @ variables, or returning different info in different applications?
Cheers, M@
At 19 JAN 2022 07:26PM bshumsky wrote:
Hi, Matt. Sorry, perhaps I mispoke in the other posting - I often deal with the delimiters as they come through in COM/.NET controls, but haven't used them in an actual OpenInsight application for some time. So please do NOT take my comments as gospel…
Hope that clarifies things,
- Bryan Shumsky
At 19 JAN 2022 07:54PM Matthew Crozier wrote:
Hi, Matt. Sorry, perhaps I mispoke in the other posting - I often deal with the delimiters as they come through in COM/.NET controls, but haven't used them in an actual OpenInsight application for some time. So please do NOT take my comments as gospel…
Hope that clarifies things,
- Bryan Shumsky
Ah, but we do take your comments as gospel, Saint Shumsky ;)
Yes, that helps - thanks :).
Cheers, M@