camste
30th September 2009, 21:53
Hi,
I have created a print session with a custom session script. It compiles without problems. The problem now is that when I've given in my search criteria in the form and I'm performing the search, the BW messages screen pops up with this message:
1: process 39 - Fatal error : Error 1918 (brd_errno 1918) on SELECT
2: process 39 - Fatal error : can not continue in tcepo0441m000 (brp.open.language)
What could be the cause of this? Is there anywhere one can find out what these error codes mean?
mark_h
30th September 2009, 23:46
How are you opening the report? Maybe post that code.
sushil
1st October 2009, 07:37
If your Db is Oracle then it must be ORA-00918 error
http://www.google.com/search?client=opera&rls=en&q=ORA-918&sourceid=opera&ie=utf-8&oe=utf-8
camste
1st October 2009, 13:22
Well, I can't see how this oracle error could occur.. Everything is prefixed. When I try to rewrite the query slightly so that it can be run in oracle (and I then try to run it in SQL developer) it works fine. This is the query I'm using. When I try removing the tcepo020 table the query works fine, but I have no idea what could cause an error in there.
select
tiitm001.*,
tiitm901.*,
tcmcs015.*,
tdltc001.*,
tcepo020.date1, tcepo020.refa
from tiitm001, tiitm901, tcmcs015, tdltc001, tcepo020
where tiitm001._index7 inrange { "EPL", :item.f } and { "EPL", :item.t }
and tiitm901.item refers to tiitm001.item
and tdltc001.item refers to tiitm001.item
and tcepo020.item refers to tiitm001.item
and tcepo020.clot refers to tdltc001.clot
and tiitm001.ctyp refers to tcmcs015.ctyp
and tdltc001.clot inrange :clot.f and :clot.t
and tiitm001.dscd inrange :dscd.f and :dscd.t
and tiitm001.dscc inrange :dscc.f and :dscc.t
and tcmcs015.dsca inrange :class.f and :class.t
and (:ecpgp = 0
or tiitm901.ecpgp = :ecpgp
or (:ecpgp = 4 and tiitm901.ecpgp =6))
and tcepo020.date1 inrange :data.f and :data.t
and tcepo020.date2 = 0
The definition of tcepo020:
Field Name Description Domain Datatype Physic. Mand. Acti Refer. Reference
length Table Mode
1 orno1 Num ordre sortie tcorno Long 4 Non Oui
2 pono1 Num ligne sortie tcpono Integer 2 Non Oui
3 date1 Date sortie tcdate Date 4 Non Oui
4 cuno1 Client sortie tccuno String 6 Non Oui
5 refa Compte client tcrefa Multi Byte 30 Non Oui
6 item Article tcitem String 16 Non Oui
7 clot Lot tdltc.clot String 16 Non Oui
8 rabais Rabais tcdisc Float 4 Non Oui
9 orno2 Num ordre retour tcorno Long 4 Non Oui
10 pono2 Num ligne retour tcpono Integer 2 Non Oui
11 date2 Date retour tcdate Date 4 Non Oui
12 cuno2 Client retour tccuno String 6 Non Oui
13 comment Commentaire archivé tdilc.mesg Multi Byte 95 Non Oui
14 fdat Derniere facturation tcdate Date 4 Non Oui
15 dref Dérnière modif. tcdate Date 4 Non Oui
16 logn Utilisateur tclogn Multi Byte 16 Non Oui
mark_h
1st October 2009, 21:25
Do you get any information in the Oracle log file?
camste
2nd October 2009, 15:38
Unfortunately I don't have the rights to access the log.
mark_h
2nd October 2009, 15:52
Are we talking the same log file - as far as I know everybody should have the rights to the log file in the $BSE/log directory. Ours is log.oracle8. Another thing you can try is to set up a trace file using something like -- -keeplog -logfile tracefile.log -set TT_SQL_TRACE=0200. I am not sure if it will help, but it might let you see more about the query. The only other thing I can suggest is to add each piece of the tcepo020 part of the query back in one section at a time. That might tell you which piece is causing the problem.
sushil
3rd October 2009, 07:45
you could try ttstperrlog.
camste
7th October 2009, 14:38
Ah, the log I was talking about was the oracle one, not the one within baan. In ttstperrlog under log.oracle8 I can see that the oracle error is indeed ora-00918, but that log doesn't tell me anything more. I tried looking at log.ora.sql, but that one doesn't have room for the whole query in its column, so I'm not able to execute the whole query on the db manually. However, I was able to rewrite the query in Baan a little bit, and get at least all the entries in the from part of the query into the log. It is adding the tiitm001 table twice in the query, with the same alias for some reason, so this is causing the error..
My baan query after stripping it down a little:
select
tiitm001.item
from tiitm001,
tdltc001,
tcepo020
where tiitm001.item inrange :item.f and :item.t and tiitm001.csig="EPL"
and tdltc001.item refers to tiitm001.item
and tcepo020.item refers to tiitm001.item
and tcepo020.clot refers to tdltc001.clot
and tdltc001.clot inrange :clot.f and :clot.t
and tiitm001.dscd inrange :dscd.f and :dscd.t
and tiitm001.dscc inrange :dscc.f and :dscc.t
and tcepo020.date1 inrange :data.f and :data.t
and tcepo020.date2 = 0
The query executed by Oracle (the part I can get out of the log, which is without the conditions in the where clause)
SELECT c.t$item
FROM ((( tcepo020 a LEFT JOIN tdltc001 b ON b.t$clot = a.t$clot)
LEFT JOIN tiitm001 c ON c.t$item = a.t$item)
LEFT JOIN tiitm001 c ON c.t$item = b.t$item)
I removed all the "refers to" (since this seemed to confuse baan while generating the query) and just used = signs instead. Now it works. An annoying problem though.
sushil
8th October 2009, 09:57
by default Oracle alert log will be at "$Ora_home\rdbms\trace" .
Try running the session in Dev environment in single user mode and trace the query from OEM.
thus you will know the Sql query run in oracle from baan apps.
wiggum
8th October 2009, 14:06
Try this query as your query based upon table tcepo020 and not tiitm001:
select tcepo020.item
from tceop020, tiitm001
where tcepo020.item inrange :item.f and :item.t
and tcepo020.date1 inrange :data.f and :data.t
and tcepo020.date2 = 0
and tcepo020.clot inrange :clot.f and :clot.t
and tcepo020.item refers to tiitm001
and tiitm001.csig="EPL"
and tiitm001.dscd inrange :dscd.f and :dscd.t
and tiitm001.dscc inrange :dscc.f and :dscc.t