Can't edit rowset of Oracle 10g table
I used to use oracle 8.1.x for my development server. Today, we manage to change the server to 10g R2 than runs on a linux box. When I edit my rowset that resides in the sessionbean, it takes forever to open the rowset. So, long that I have to kill the JSC2. I have the same scheme in another 8.1.x oracle server, but it seems to be OK with that. I also ask my friend to do the same with her PC, but the result is the same. So, somehow, it goes wrong with JSC2u1 with the oracle 10g. It works ok with oracle express. Anyone knows the answer of this one?
It is funny that I CAN see the columns, and the data in server palette. It means that the jdbc can read the metadata. But, why doesn't it work when editing the rowset?
Right now, I have to manually edit the Sessionbean1.java to change or add the rowset.
regards,
[843 byte] By [
discusfish] at [2007-11-26 11:46:21]
# 3
Ok. I ask my database admin's help to find out what JSC2 do when I edit the rowset. Basically he captured my session id, and from the session ID, he could get any queries being made by JSC2 to the oracle.
THE SCHOCKING REALITY IS:
Whenever I try to edit the rowset, somehow the JSC are querying ALL TABLE'S metadata in my schema. So.. if you have 1000 tables in your schema, JSC will query ALL tables' metadata (and probably views, I didn't check it, because that was enough for table). NO WONDER IT TAKES FOREVER to just edit one rowset.
Question is: WHY JSC designers do that? Why? Why not just request the table instead of all table?
I think someone has to submit this as a bug (or design flaw).
# 4
I磎 using oracleXE with the ojdbc14.jar... and tomcat
In just two page I磎 receving the following msg
* Number of conflicts while synchronizing: 1 SyncResolver.DELETE_ROW_CONFLICT row 2 won't delete as values in database have changed: 2006-11-29
* Cannot commit changes: Number of conflicts while synchronizing: 1 SyncResolver.UPDATE_ROW_CONFLICT row 0 values changed in database
when i tried to delete or commit the updated changes in the register...
My query is bellow:
SELECT ALL PATRIMONIO.TB_BEM.INCODIGOBEM,
PATRIMONIO.TB_BEM.VATOMBAMENTO,
PATRIMONIO.TB_BEM.VAMATERIAL,
PATRIMONIO.TB_BEM.INCODIGOSETOR,
PATRIMONIO.TB_SETOR.VANOME AS NOMESETOR,
PATRIMONIO.TB_BEM.INCODIGOFORNECEDOR,
PATRIMONIO.TB_FORNECEDOR.VANOME AS NOMEFORNECEDOR,
PATRIMONIO.TB_BEM.DACHEGADA ,
PATRIMONIO.TB_BEM.DASAIDAPREVISTA,
PATRIMONIO.TB_BEM.DASAIDAEFETIVA,
PATRIMONIO.TB_BEM.VAMARCA,
PATRIMONIO.TB_BEM.VAMODELO,
PATRIMONIO.TB_BEM.VADESBAIXABEM,
PATRIMONIO.TB_BEM.INCODIGOTIPOAQUISICAO,
PATRIMONIO.TB_TIPOAQUISICAO.VANOME AS NOMETIPOAQUISICAO
FROM PATRIMONIO.TB_BEM , PATRIMONIO.TB_TIPOAQUISICAO, PATRIMONIO.TB_SETOR, PATRIMONIO.TB_FORNECEDOR
WHERE PATRIMONIO.TB_BEM.INCODIGOTIPOAQUISICAO = PATRIMONIO.TB_TIPOAQUISICAO.INCODIGOTIPOAQUISICAO
AND PATRIMONIO.TB_BEM.INCODIGOSETOR = PATRIMONIO.TB_SETOR.INCODIGOSETOR
AND PATRIMONIO.TB_BEM.INCODIGOFORNECEDOR = PATRIMONIO.TB_FORNECEDOR.INCODIGOFORNECEDOR
AND PATRIMONIO.TB_BEM.INCODIGOBEM LIKE ?
AND PATRIMONIO.TB_BEM.VATOMBAMENTOLIKE ?
AND PATRIMONIO.TB_BEM.VAMATERIAL LIKE ?
AND PATRIMONIO.TB_SETOR.VANOME LIKE ?
AND PATRIMONIO.TB_FORNECEDOR.VANOME LIKE ?
ORDER BY PATRIMONIO.TB_BEM.VATOMBAMENTO ASC
Why this problem is happing? Did you had some solution for that? Is the problem because the query is too long?! In jsc with the jdbc from the app... this is working fine.
please help me!
# 5
> THE SCHOCKING REALITY IS:
> Whenever I try to edit the rowset, somehow the JSC
> are querying ALL TABLE'S metadata in my schema. So..
> if you have 1000 tables in your schema, JSC will
> query ALL tables' metadata (and probably views, I
> didn't check it, because that was enough for table).
> NO WONDER IT TAKES FOREVER to just edit one rowset.
>
> Question is: WHY JSC designers do that? Why? Why not
> just request the table instead of all table?
>
I talked to one of the dev's at java one and it's supposed to cache the metatdata - so it should only be slow on the first one. Why it's not doing thatfor you would then be a bug. Are you sure you let it finish successfully?
My experience on a large database (Siebel) was that Oracle metadata retrieval is painfully slow. Very painful. And a large number of tables might mean you need to increase creator memory.
I gave up using the query editor and just type in my query manually in the view data window or sometimes edit just the code. I follow jfbrown's non-documented "useViewData" hack in blog http://blogs.sun.com/jfbrown/entry/view_data_trivia
to avoid the query editor accidentally opening. This worked before update 1 but I expect it also works in update 1.
-Tub
