The order of a DBDataSource - A unique key (index) can help (but...)

[Former Member]

Hi @all!

There was often the question, if a DBDataSource could be ORDERed BY sth. Although it would be nice if somebody could disprove that: It's not possible.

Up to this my experience was that the "items" in a DBDataSource always ordered by the Code-Column. That's what my code in some situations relys on. For example if a B1-form browses by a DBDataSource then the order is not always user friendly based on a column with data the user knows.

But today I was surprised: "Suddenly" a DBDataSource-browsing form is browsing correctly by a DB-Column which the user is interested in (instead of the code-column) !

The reason for this is a unique UserKey, which I've created by SDK (UserKeysMD). The form seems to browse by the columns of the key.

But the common reason seems to be that it's standard SQL-behaviour because doing a simple query (without ORDER BY) in SQL-Management Studio also sorts the results by the unique key.

But there's one important question left:

Which key wins and why? There's also the unique index for Code on that table....

Cheers,

Roland

[Former Member · Accepted solution]

Roland,

it flustrating, but it seems that datasource is sorting it randomly (depends on indexes in table). That was the reason why Im using datatables with order by statement instead of datasources...

Petr

[Former Member · Accepted solution]

That are really bad news :-((

But DataTables are only useful for Matrixes (I thought).

Could this also be done with DataTable?

Or is there any good alternative for a defined ORDERed browsing within a form (yellow arrows)?

[Nussi · Accepted solution]

Roland,

weil Du BenutzerForm schreibst. (gelbe Pfeile)

in einem UDO verwendet man doch BrowseBy für die Sortierung.

oder versteh ich was falsch ?

lg David

[Former Member · Accepted solution]

Hello @Petr & @all ,

last night I came to the conclusion, that I must re-implement the browsing for the 6 existing forms with own code:

Stepping through a recordset with the data of the Ex-BrowseBy EditTxt with defined ORDER

Then loading the form with DBDataSource which is restricted by conditions to exactly ONE dataset on each arrow-step. I hope/think it works - I will inform you.

And here are some things to sort out with David {german - sorry}:

Hallo David,

ich habe hier kein UDO verwendet weil...

...die Forms viele spez. Funktionen haben die dadurch nicht (oder nur komplizierter) möglich wären.

...hauptsächlich aber weil die betroffenen Tabellen auch von einer Schnittstelle zur Betr.-Datenerfassung "gespeist" werden (also nur über DI)

BrowseBy funktioniert ja auch ohne UDO über ein EditTxt welches an eine column in der tabelle DBDataBinded ist und für das "BrowseBy" aktiviert ist.

Dies ist für die Tabelle/Formular mit den Hauptobjekten auch ok: es wird automatisch durch alle Hauptobjekte geBrowsed und nach Code wäre zumindest chronologisch alles richtig gewesen (auch nicht schön von dieser Vorgabe abhängig zu sein - hat sich ja jetzt aber erledigt, da die Indexe alles undefiniert würfeln)

Die Sache wird aber noch etwas komplizierter, da die Hauptobjekte drei mal in Unterobjekte aufgeteilt sind, für die es jeweils auch Formulare gibt. Und diese Formulare sollen nur innerhalb eines Teils der zugehörigen Untertabelle browsen. In der Untertabelle sind aber alle Unterobjekte aller Hauptobjekte enthalten.

Also habe ich für die Unterobjekt-Form die DBDataSource nach der geBrowsed wird mit Conditions eingeschränkt. Schon hier mußten die Pfeile mit eigener Funktion belegt werden (B1 automatik reicht da nicht)

Beim browsen in den Unterobjekten ist durch die indexe natürlich nun auch alles durcheinander.

Das ganze fiel auch nicht sofort ins Auge weil "meistens" Code und eigentliche ObjektSchlüssel durch "chronologische" Eingabe (bzw. import) die gleiche Reihenfolge haben.

Nur ein Versuch das "mal so eben" zu erklären...

Viele Grüße,

Roland

[Nussi · Accepted solution]

Oh Mann Roland,

Dein Programm scheint echt kein Honig lecken zu sein.

ich hoffe das es nach der Neu-Implementierung passt.

lg David

[Former Member · Accepted solution]

Thanks David & Petr,

your statements and wishes have brought me forward in my decision to do it another way.

What I'm doing now (and it already seem to work ) ...:

- Loading a DataTable (not bounded) only with the Code-Cols ORDERed by the things THAT I WANT. Since a DataTable also provides an Offset-property (like DBDataSource) it was easier to re-implement than a RecSet.

- On every yellow-arrow step the offset is switched for-/backward regarding the beginnng and ending (stepping is cycling)

- On every yellow-arrow step the already existing DBDataSource is loaded with the condition of "Code equals the code of the actual step"

Performance is ok (and mostly influenced by another SELECT...which has leaded to the indexes....which leads back to the start of this thread).

(happy end - tachacka )

Cheers,

Roland