Toad World® Forums

Developement Team and different Databases (Stages) with QCTO


Maybe someone can give me a tip about team testing on different database instances (staging).

Our staging environment:

DEV1 - Database instance for developement
PRE1 - Database instance for integration tests (pre-production)
PRO1 - Database instance for production

We think it might be good to enable the QCTO on all 3 instances. So I can test on DEV1 and also run the same test-case on PRE1.
So I thougt about installing a new repository instance:

REP1 - Database instance for repository

On REP1 I installed the QCTO repository and db-links to DEV1, PRE1, PRO1.
On DEV1, PRE1, PRO1 i created public synonyms to the QCTO objects on REP1.
Now I start QCTO and when connecting on DEV1 or PRE1 or PRO1, following QCTO error appears:
ORA-00604: error occurred at recursive SQL level 1
ORA-00900: invalid SQL statement

(of course it would work when i directly connect to REP1, but thats not what i want)

Actually I dont want to store a repository (with kind of “productive” test-cases) on a developement instance.
This is a problem. We’re in a small environment. Usually our developement team is developing pl/sql code on DEV1. Of course they should also test on DEV1.
On some times, the complete PRO1 database will be copied to DEV1 (kind of initializing).

Does anyone have an idea?



Code Tester is currently an instance-specific tool. You cannot install the repository/backend on INST1 and use it from INST2.

You will need to install the product and backend on each of your instances, and then use the export/import feature to move definitions and test code between the instances.

Perhaps someday we will extend Code Tester to support this, but it is not possible today.

Regards, Steven


If this were done, then you would have to version your test cases. Consider the when rsion 1 of your code is in PRE and version 2 of you code in DEV - they would have to have some differences in their tests


You’re right. I didn’t consider this. This could get pretty complicated. But it could be very interesting finding a solution for this …


One thing we will be doing, starting with 1.6.1 (due out in the Fall - previously known as 1.7, with betas available starting in August), is that we will save a snapshot of your source code along with the test definition. Thus, when you export, you export the code that was being tested at this time.

That way, you will be able to selectively restore a version of your source code that is consistent with the test definition.