This has been brought to my attention by a colleague using 12.9 but it is doing it in 12.10.0.6 too.
Open 2 different database connections but have just one editor window. Open a view (or just write some code) in one tab and switch between database connections. It switches immediately and all is good. Now open a database package script (just one stored as a .pkg file in your file system) and then try the connection switch; this time it takes 15-20 seconds. Switch back and it takes 4-5 seconds. This is all while connected as Apps and the package owner is apps.
When trying the same exercise when connected as something other than Apps, the connection switch takes over a minute - I suspect it is looking through all of the packages in the schema browser. When connected as apps this takes a little while but when not apps, it takes much longer as it needs to refer to synonyms.
We are an ebiz site so the Apps schema has over 45000 packages in it!
I have tried the same thing in 12.8.0.49 and the delay does not happen.
Do you have an object palette open or Team Coding Manager? Both of these windows run queries when you change active connections.
APPS schema owns a TON of objects. The delay is likely setting the edit control to highlight all of those names. You can disable the highlighting of object names on the Editor|Display page in Options. I should probably add a schema exclusion list there so you can turn it off for selected schemas.
Michael
All 3 of the Object Name Highlighting checkboxes are unchecked (just as they are in 12.8). Have I misunderstood which bit you meant?
Uncheck all three and test again. I would expect similar object name highlighting performance between 12.8, 12.9 and 12.10 beta. Was 12.8 affected as well?
They were already unchecked but I checked them, tested it then unchecked them again and tested it. Performance was the same with both sets of settings.
It affects the 12.10 beta and 12.9 but 12.8 is unaffected.
Thanks,
Mark.
Sorry, I missed that you already said unchecked. I got to a position to look at it and I see what you’re saying. There’s a query against [user|all|dba]_arguments that’s slow. It has come up recently through support as well. I will take a look at this today.
Thanks,
Michael
This is fixed for 12.10. The next public beta has the fix in place.
Thanks,
Michael
Excellent. Thanks Michael.