Hi DataEase

I created a form based on a table with some predefined filters on QBM.

on a button of the form via OML I launch an update procedure using MemoexecDQL.

Here the OML

----------------------------------------------------------------------------------------------------------------

define "a" numeric string 1 .

assign a:= setvar("TImportoFidoRichiesto",ImportoFidoRichiesto.value) .

assign a:= setvar("TImportoFidoRichiesto_DiCui_Bondanet",ImportoFidoRichiesto_DiCui_Bondanet.value) .

assign a:= setvar("TContraente", Nome_Contraente.value) .

assign a:= setvar("TNote",Note.value) .

a := MemoexecDQL(any DQLStore with (DQLNumber = 0005) DQLScript , N_Protocollo.value , "" , "" , "" , "" ) .

a := keystrokes ("_ctrl(r)") .

if getvar("CheckEvasione") = "OK" then

message concat("Richiesta Analisi finanziaria eseguita. Protocollo N. " , N_Protocollo.value) window .

a := FormClear() .

end .

---------------------------------------------------------------------------------------------

The procedure works well but if a filter is made by the user on this form the DQL launched does not correspond to the number indicated on the expression with, i.e. the DQL 0001 is launched instead of the DQL 0005

I tried to :

1) reorganize the DQLStore table (no results)

2) change the format of the DQLNumber field from numeric string to number (no results)

3) I entered named "xxxxxxxxxxx" in the MemoExecDQL command (no results) I tried also combination of point 2 and 3

4) I try to run memoexecdql via execute function derivation without using OML (no results)

NOTE

there is no relationship on DQLStore (I think it is right so )

Any suggestions?

Hi Marco.

Sounds strange. We know that some strange things can happen when you combine OML and ExecDQL. 

We will try to see if we can replicate the problem and get back to you.

Here a test database as requested. Please unzip and open it. Work on VTestMemoDQL and follow the istructions. no userid / password i requested.

Hi again Marco.

Sorry for the delay in responding.

You have found an old bug that was still there in DE9 too.

The problem is that the relationship that is created in memory due to the any statement is cleared together with all the other relationships when you change the query.

A new query in DataEase result in a completely new multiview and for some reason the OML stuff is not part of the new multiview and hence the any will hit the unfiltered "virtual" relationship and return the first row in the table.

We have fixed this in DE9 but obviously this bug is still there in 8.5.

The best way to get around this is to use the standard memoexecdql() "Hack" of adding a virtual ExecDQL and Relationship key in the form. 

You can also use LabelExecDQL() and hide the code with SetState().

In DE9 you will be able to run DQLs stored in the system execdqlstore table directly with ExecDQL("#0005" etc. or ExecDQL("@Dqlname here" etc or use AnyLookup() to look up data without a pre-existing relationship.