"GetNthRecord" baseert zich niet op gewenst record

[Dirty May]

'GetNthRecord' baseert zich blijkbaar onveranderd op het recordnummer dat gegenereerd is op basis van de volgorde van oorspronkelijke invoer, en niet op het recordnummer na sortering volgens een andere sorteervolgorde.

 

Is dit een bug, snap ik iets niet, of doe ik iets verkeerds ?

[hbrendel]

Is het mogelijk dat in je proces de sorteervolgorde verloren gaat?

[JeanWM]

FMH zegt ook:

 

The result of GetNthRecord() will not be updated when the record referred to by GetNthRecord() is a record other than the one in which the calculation is currently being evaluated.

[Dirty May]

" be updated "

 

Zelfs initieel loopt het al mis.

 

Heb het ondertussen wel al opgelost, zij het eerder 'by trial and error' en vooral door toeval.

 

Het is in ieder geval zo dat ik het niet 100 % meer snap : in een layout moeten twee reeksen velden ingesteld worden, met informatie uit twee verschillende tabellen. Voor allebei deze tabellen is een relatie gecreëerd die gelijkaardig is. Toch zijn er met de in te vullen velden problemen als ik ze onder de ene relatie onderbreng en niet onder de andere.

 

Zie op het ogenblik de reden niet.

FM kan tezelfdertijd poepsimpel zijn en immens ingewikkeld. In dat laatste geval kan je al eens den draad kwijtgeraken.

 

In ieder geval dank aan allen die op dit item gereageerd hebben.

[Jeroen Aarts]

Ik heb het vermoeden dat je verkeerdelijk verwacht dat een sortering van gerelateerde records op een bepaalde layout, een invloed heeft op de volgorde van die gerelateerde records op zoals die bekeken wordt in de relatie tussen hoofdtabel en gerelateerde tabel. Dat is dus niet het geval.

 

Als je met GetNthRecord() gerelateerde records overloopt, dan geldt enkel de sorteervolgorde opgegeven in de relatie van hoofdtabel naar gerelateerde tabel. Als er geen sorteervolgorde is opgegeven, dan geldt de aanmaakvolgorde van de gerelateerde records.

 

N.B. Sortering beïnvloedt GetNthRecord() wél als je er geen gerelateerde records mee opzoekt, maar records opzoekt op basis van dezelfde table occurrence als de actuele layout. Dat wil zeggen als je een TO A hebt met een veld Nummer met nummers van 1 tot 1000; dan krijg je effectief andere uitkomsten met GetNthRecord(A::Nummer;1) bv. als je aflopend of oplopend sorteert.

 

Hopelijk is dit niet te verwarrend

 

- Jeroen

[Dirty May]

Verwarrend is het alleszins.

 

Tabellen en relaties kunnen al gauw een gecompliceerd kluwen worden.

Als er dan nog andere aspecten bij komen kijken zoals GetNthRecord dan gaat mijn simpel brein wel helemaal in de knoop.

 

Ik stel de vraag efkens anders :

 

ik pluk gegevens uit een gerelateerde tabel waarin de records op een bepaalde manier gesorteerd zijn. Op basis van die sortering vraag ik de gegevens van dat 1ste record, dan van dat 2de record.

 

Maar in de tabel van waaruit ik de gegevens opvraag en waarin ze moeten in veld ingesteld worden, blijkt dat die gegevens dan ineens weer in volgorde aankomen die die is van de ongesorteerde volgorde ( = aanmaakvolgorde ).

 

Maak ik het nu niet nodeloos moeilijk om begrijpen ?

 

Als dat klopt, vraag ik me af of er iets kan aan gedaan worden.

[Jeroen Aarts]

De volgorde wordt in jouw situatie enkel bepaald door de sorteervolgorde die je opgeeft in de relatie tussen tabel 1 en tabel 2. Daar ligt dan ook de oplossing

[Dirty May]

Heb het probleem opgelost door de reeks records eerste te sorteren zoals gewenst, ze dan efkens te parkeren in een identieke tabel, de oorspronkelijke tabel te ledigen, en dan de reeks terug te zetten in zijn oorspronkelijke tabel. Dat alles uiteraard via een script.

 

Het is geen oplossing waar ik trots op wil zijn, elegant is ze zeker niet, maar het werkt, en ik kan momenteel niets beters verzinnen. Dus ...