Ive been pointing out errors in Numeric View schemes for a while now (first it was Decade, the BPM) ... now it is TRACK ...
Granted, noone would really create a TRACK view scheme (or I cant think of a reason) .. but looking at it ... it really shows me how the coding was done ...
There is a group for UNASSIGNED, "0", & "00" ... all with the same values .. Also, there is a "01" and a "1" grouping (same files).
The ordering is 1 ,10,100,11,12,13, 2 ,21,22,223,23 ... Anyone see a problem
The last time I saw these kinds of problems we were working with a database at work that had numerical values and the key was listed as 'string' and should have been interger(32). As a string it was doing a 'best-fit' analysis of the values ... causing the numbering to be 1,10,100,11,12,etc ...
From what Ive seen, there have been regressions caused by certain changes in the DB ... and then, after a few changes, the view scheme for the particular problem I'm addressing get fixed. I don't think that the problem is being addressed as a whole, but rather in the view scheme (altering each code separately to handle the new view scheme I bring to the table) ... I think a DB change would be more important at this point. Making each field defineable as string vs text to make the coding simpler (and the ordering will work at that point).
If we are going to be allowing users to create "CUSTOM FIELDS" in the future and make View Schemes based on these custom fields, you will have the same problems that have been cropping up that I have mentioned previously for BPM scheme, Decade scheme, & Track scheme.
Author
Topic: Numeric View Schemes - still messed in 90067 (Read 1109 times)