Announcements
80
I have a DbNav (Grid) that, when user inserts data, the row moves to de corresponding order position.
But i have another DbNav (Grid) in other screen, that... the inserted data is secuencial... always new data is inserted in the last row of the grid...
so this is a configuration issue?
How can I make the second grid to behave as the first
*This post is locked for comments
Mauricio
Sorry - I have no further suggestions.
Barry
Barry thanks again for both posts... but..
Here is the DetalSetup from first screen :
>> mhandle = detailsetup(c1, Spread1, PNULL, bXDocDgiSol, PNULL, PNULL, PNULL)
And here is the other one:
>> mhandle = DetailSetup(c1, Spread1, PNULL, bxVendorRetencion, PNULL, PNULL, PNULL)
In both cases don't use LineNbr to identify the inserted/edited/deleted row.
In both cases the SAFMaskedText boxes are marked with "0,k" according to the unique primary key of the table...
should be something easy that I can not realize what is the difference between them
:/
Mauricio
On quiet reflection, there's at least one other factor which influences where new grid lines are inserted.
In the DetailSetUp call in Form Load, the optional 3rd parameter specifies an "auto line number" field.
If that parameter is populated, then new lines are inserted wherever the operator chooses to insert them.
Usually at the end of the grid - but they can be inserted anywhere.
at SAVE time, the kernel populates the LineNbr field with a value that places it in that position.(In other words, if the operator has inserted a new line between lines with LineNbr values of 256 and 512, then the new row will be assigned a LineNbr between those two numbers.
If this sort of Line Numbering is in effect, then the "order by" clause of the DBNav SQL will have LineNbr as the last field,, so that the grid is loaded in that sequence.
Screens like 08.010, 03.010 are examples of this sort of screen.
You may want to have a look at your DetailSetup call. Idf it populates that "LineNbr" parameter, then the screen will be operate as I have just described.
Hope that helps...
Barry
A brief comment on the wildcard aspect of the DBNav property.
The DBNav SQL is used in two situations:-
- To load the grid
- To Insert/Update/Delete a specific row in the grid.
Lets assume you are loading all Docs for a given CustId into a grid.
One parameter is, say, RefNbr.
In order to Update/Delete, the parameter values the kernel passes to the SQL need to identify the single row that is being updated/deleted.
So, a value like 000123 will be passed as the RefNbr parameter.
That (along with DocType etc.) identifies a single document.
But when the grid is being loaded, you want all documents for the customer.
So you want % (the wildcard chatacter) to be passed as the RefNbr parm.
Checking the Wildcard box for the RefNbr parameter will cause that behaviour.
---
The "order by" clause of the DBNav will determine the initial population of the grid.
If it is "order by RefNbr" then the grid will initially be populated in RefNbr sequence.
---
But that's about where the influence of the DBNav peoperty ceases.
To my knowledge, when the operator inserts new row, it is the Level property of the individual controls that determines where it will be inserted.
If any controls have that ",k" in their Level property, then the kernel will insert the new row so that the grid is in sequence on that "key field".
That's my understanding of how it works.
Barry
Thanks for your answer Barry:
Level 0: yes
Both grids Level: 0,K
The only difference I found, is "Wild Card" parameter. First grid have it all checked, second grid not.
I suggest that you look at the Level property of the controls involved.
I'll assume that the grid is Level 0
The controls for the "key fields" should have a Level of 0,k
The controls for "normal fields" should have a Level of 0
Barry
#1
Community Member
136
#2
Mohamed Amine Mahmoudi
102
Super User 2025 Season 1
#3
REUser
8
Share
Report
All responses (
Answers (
