I want to share a solution with you for a situation mentioned several times on this board:
I want to use AFS in a session where I could not manage to select the right record to update although the syntax in AFS is correct. ret = stpapi.sort.by("tdisa0601m000", "1", o.err.msg)
stpapi.put.field("tdisa0601m000", "tdisa001.item.segment2",
trim$(tdisa001.item))
ret = stpapi.find("tdisa0601m000", o.err.msg)
if ret = 1 then| But once here it appears that something is DEAD WRONG
Note: I thought that the session had to be started (and finding the default record selection would be done after the index selection) before I do a put on the session, but that does not help. stpapi.get.field("tdisa0601m000", "tdisa001.item", item)| item is not the same as tdisa001.item but *another*

So I figured out the solution offered on the board, using browse.set (or browse.view, depending on the session type) but it takes an awful lot of time to get things done since we have loads of items to sell: if not ( trim$(item) = trim$(tdisa001.item) ) then
repeat
if item < tdisa001.item then
ret = stpapi.browse.set("tdisa0601m000", "next.set",
o.err.msg)
else
ret = stpapi.browse.set("tdisa0601m000", "prev.set",
o.err.msg)
endif
stpapi.get.field("tdisa0601m000", "tdisa001.item", item)
until ( trim$(item) = trim$(tdisa001.item) or ret = 0 )
endifThis works for sure, but it has to browse through all items before it may continue with the correct one. And this has to be done many times for all items on my to-do list.

When running a DBS log I noticed that the record marked as *another* item was the *saved default* item (or after I removed my defaults it appeared to be the *first* item).

Now I added a trick :D
Before the first AFS call on the session where I need the record, I trick the 4GL session by setting the defaults in the stored session defaults to my current record -> update.current.tools("tdisa0601m000", "tdisa001.item:=" &
quoted.string(tdisa001.item), ttyeno.yes)
Where the function is defined like:functions:
function update.current.tools( domain ttst13 i.sess,
domain ttst200 i.rcrd,
domain ttyeno i.socc)
{ | Note: i.socc = yes means single occ (no = multi occ)
table tttadv990
long companion
companion = get.compnr()
if compnr.check(000) then
db.retry.point()
select ttadv990.*
from ttadv990 for update
where ttadv990._compnr = 000
and ttadv990._index1 = {:logname$, :companion, :i.sess}
selectdo
db.delete(tttadv990, db.retry)
endselect
commit.transaction()
db.retry.point()
select ttadv990.*
from ttadv990 for update
where ttadv990._compnr = 000
and ttadv990._index1 = {:logname$, :companion, :i.sess}
selectdo
selectempty
ttadv990.user = logname$
ttadv990.comp = companion
ttadv990.sess = i.sess
ttadv990.sequ = 1
ttadv990.socc = i.socc
ttadv990.rcrd = i.rcrd
db.insert(tttadv990, db.retry)
endselect
commit.transaction()
endif
if compnr.check(companion) then
endif
}It seems to work fine for me ;) Please tell me if it works for you too :cool:

Quite a hack! :)

What if we simply clear the defaults before running the AFS and not saving any defaults? Because, there are instances when even the device details are stored by users as defaults and which does cause problems.

Quite a hack! :)

What if we simply clear the defaults before running the AFS and not saving any defaults? Because, there are instances when even the device details are stored by users as defaults and which does cause problems.

Removing all defaults will lead to finding the first topmost record and thus not solve the problem. We force the wrong RIGHT found record to be presented as the first by session defaults.

Hi,

I think I had a similiar problem with a session that had start option 44 "get defaults". I got around by copying the session and changing the start Option.
But I'm on Baan IV.

Regards
Günther

Nice hack and thanks for sharing it. I can't remember which session it was that I did where the stpapi.browse would move to the next record but would not make it current(no stpapi.mark did not work) - all the actions tried to happen on the first record. I believe what I did was stpapi.browse, get fields, then execute a stpapi.find to make it current. But this is a hack I never thought of - great solution.

Same here Gunther. Then one of the first things I do it a user calls and says one function servers is not working is to delete all user defaults for all sessions.

Plus it looks like I need to get some updated documention. I did not even know about the stpapi.sort.by option. I might have to see if that even compiles on our 4c4 system.

I think I had a similiar problem with a session that had start option 44 "get defaults". I got around by copying the session and changing the start Option.
Yes Günther, that should also work, but I want to leave the standard functionality and operation as is without making even the slightest change.