Baan 5.0b, Solaris, Oracle

This one has me puzzled.
Since yesterday (and of course everybody assures me that NOTHING happened), users of our test company get 506 errors when trying to enter sales order lines, purchase order lines or production orders and probably some other stuff).
Super users in the same company expereince no problems.

So I put a trace (dbslog 400) on one of our users and found the following:

SQL> SELECT /*+ FIRST_ROWS INDEX_DESC(a tttadv140100$idx1) */ a.t$clab,a.t$clan,a.t$cpac,a.t$cust,a.t$desc,a.t$expi,a.t$leng,a.t$lhgt,a.t$rele,a.t$seak,a.t$vers,a.t$zb_brnc FROM baan.tttadv140100 a WHERE a.t$clan = :1 AND a.t$cpac = :2 AND a.t$clab = :3 AND a.t$lhgt >= :4 AND a.t$leng >= :5 AND a.t$lhgt <= :6 AND a.t$leng <= :7 ORDER BY 2 DESC,3 DESC,1 DESC,8 DESC,7 DESC,11 DESC,9 DESC,4 DESC,12 DESC

notice that it is looking for ttadv140 (Labels by package VRC) in company 100, but the table is of course located in company 000.

Now how can that happen, when superusers in the same company have no problem at all?

huh? huh? huh?

...it is coming from the user authorization role.

In other words, I can fix the problem by changing the role assigned to the user(s), which makes me happy, makes the users happy, but still doesn't explain why it is looking in comapny 100.

:confused:

There have been problems in the tools with switch to company 000 and back... Try to find updates on tools components that reflect the changes recently done.

That you suddenly experienced the problems might look spooky, but there must be a reason. From software updates only now activated (shared mem / RDD / disk caching), via user authorisations (newly set / only just now RDD), and reboot to even just now started to test this specific part.

Can't fool this ole bastard ;)

But it still puzzles me what twisted logic causes a lack of authorization to look for a 000 table in company 100....

....and how I can use that to my advantage. lol

What does tracing and logging reveal about this?

imho, this is where software updates comes and look around the corner (om het hoekje komt kijken :)).

The trace is listed above and the logs just give me the 506 (but no table).

uhm, I think you also would like to know what function is triggering that sql statement. What if you repeat the tracing with `-- -dbgfun -dbgrefer -dbgbdbact -dbggpvar` options as well?

-dbgfun : debug functions
-dbgrefer : show references
-dbgbdbact : show bdb actions
-dbggpvar : debug get & putvar

What time do you have right now... Must be deep in the middle of the night.

Which not only refers to the time I staid up last night, leading the geek squad and strutting my Baan, but also to this issue.

We already fixed the role that was causing this problem, which makes it a pure theoretical question now. Nothing to lose sleep over ;)