Getting an error in TDP 5.3 when I open certain queries and try to change the database connection to my user id:
The objects that are used in your workbook flows... do they exist in the other database connection? Or, if it's the same database, but just a different user login, does your other user have the privs to see those objects?
Hi Gary, my user id and the other user id both have access to the objects used in the workbook.
OK... might need to take this one to Support, Steve.
do you use fully qualified queries?
Potentially your default db for both connections might not be the same as what you set in your Query Builder.
Hi Dan, I checked and the query in question is fully qualified. Also checked the default db connections and they were different, but since the query is fully qualified this shouldn't matter right? I tried changing the default db for the user to match mine, then had her open the query, process and re-save, but I'm still getting the same error when I open it.
FYI this error occurs in TDP version 22.214.171.1243. I'm not getting this error in version 126.96.36.1999.
Hi, I tried to reproduce but I didn't get any errors when switching users on Oracle.
- Can you try the isolated query in Editor so we can see whether it is connected to Toad or only Workbook?
- Can you send us the query file?
Dan, the query runs fine in Editor with my user id. Attached is the query file (zipped .twf file and changed extension to PDF).
Legal costs.pdf (51.9 KB)
End users at our organization are experiencing the same issue with 188.8.131.523. We are currently on 5.0 and if this occurs, we are able to remove the tables we may not have access to and then execute the query. With 184.108.40.2063, we are not able to proceed to alter the query at all.
HI Dan, any updates on this issue?
Our devs are focussed on this. To my knowledge we still haven't been able to reproduce it, we'll let you know asap.
Is there an open SR for this item? Our organization will not proceed with an upgrade until this is resolved.
we have fixed it but until the new release is out, you could try a workaround.
The new connection needs to have the same default schema as is in your query. On this condition it should be fine.
@jeanaf Yes - 16141 is the task number.
Hi Dan, is the new release out that fixes this issue? I'm running 220.127.116.113 and am still having this problem.