Descend() in index expressions, using Vulcan runtime

[wriedmann]

Hi Chris,

problem isolated.
In VO, Descend( Today() ) returns 2773423, ValType N
In X# with the Vulcan runtime, it returns 10.04.5982, ValType D

Unfortunately, the X# runtime behaves as the Vulcan runtime, even when using the VO dialect, as it returns a date value, and the same value as the Vulcan runtime.

This may be a problem when migrating Vulcan applications, but as far as I have understand the thread in 2013 about Descend() problems, no one is using the Descend() function in Vulcan.

Wolfgang

[robert]

Wolfgang,

You are right. We currently emulate the Vulcan behavior and not the VO behavior. I will change that for the next build. VO returns 5231808 - the LONG(_CAST) of the date for Descend.
And that number 5231808 is the difference between 31-12-2999 and 01-01-1900 in case you were wondering (Harbour and clipper use the same calculation).

Robert

[Chris]

Hi Wolfgang,

Thanks, yes you are right, it is a bug. I think it's possible to create a workaround though, let me give it a try and will get back to you.

@Karl, ah sorry, didn't realize you were talking about the VO implementation itself!

Chris

[wriedmann]

Hi Robert,

thank you very much!

Wolfgang

[Chris]

Hi Wolfgang,

Here's a quick fix, for now that you use the vulcan runtime. Just put this anywhere in your libraries or main exe and the macro compiler should pick this implementation at runtime:

Code: Select all

FUNCTION Descend(val)
	IF IsDate(val)
		RETURN 5231808 - (DWORD)(DATE)val
	END IF
RETURN VulcanRTFuncs.Functions.Descend(val)

Chris

[wriedmann]

Hi Chris,

this is again to demonstrate you were right when you wrote I should try to migrate my VO applications whenever possible.

Wolfgang

[wriedmann]

Hi Chris,

I have tried it, it does not fails anymore.

But somewhere later during the reindexing process my application crashes with a System.Reflection.TargetInvocationException error - I have to check it further.

But there seems to be some incompatibility between VO and Vulcan/X#, because I check if the index expression from the dictionary and the one from the index are the same - and I start reindexing only when they are not the same.
With the X# version the reindexing starts even when I have already built the indexes with the VO version.
I have to check also this one.

But in the meantime I have to continue the development of the other ported application (that uses only part of the database of a VO application, but stores the main data on a remote SQL server).

Wolfgang

[Chris]

Hi Wolfgang,

Yeah, maybe somewhere there's a difference between VO/Vulcan/X#. When you locate which index is not the same as is supposed to be, please let us know, usually it's easy to fix such issues.

Chris

[wriedmann]

Hi Chris,

this may be important when the X# RDDs are ready and in use, but I have my doubts you can do anything in the Vulcan RDDs.
The strange thing is that one order failed this check:

Code: Select all

if ( cAlias )->( DBOrderInfo( DBOI_NUMBER, cIndexFile, self:TagName ) ) == 0

The orders name is "LFNR", and the order expression is "upper(lfnr,10)", with a ordercondition of !(Inaktiv)

There are many other orders with similar name and similar expressions, and they work.

This is very strange, as this code is more than 20 years old, and has worked from VO 1.0 on....

I will check that further, but it could take a few days as I have other projects to move forward.

Wolfgang

[Chris]

Hi Wolfgang,

It depends on where the problem is, because as you saw with the Decend() function it was easy to provide a quick workaround. No rush at all, when you get the time to look into it again and andnarrow it down a bit, please let us know so we can have a look.

Chris