Oracle SQL Developer - les tables ne peuvent pas être vues
J'utilisais SQL Developer 1.1. J'ai récemment effectué une mise à niveau vers SQL Developer 3. Après la mise à niveau, j'ai remarqué que certaines de mes connexions ne montraient pas leurs tables. Je peux faire une sélection sur les tables et les données sont affichées. Je peux voir d'autres objets tels que des vues, etc. Je peux toujours utiliser ma version précédente et voir toutes les tables répertoriées correctement pour les mêmes schémas. Il y a d'autres connexions qui se révèlent bien.
Impossible de trouver des informations à ce sujet. J'ai essayé d'enlever le filtre mais cela n'a pas fonctionné.
Est-ce que quelqu'un a couru dans ça? S'il vous plaît aider.
Les tables que vous recherchez se trouvent probablement dans un schéma différent. Il y a plusieurs options. Vous pouvez soit cliquer sur Autres utilisateurs dans l’arborescence située sous votre connexion, ou faire un clic droit sur la connexion, sélectionner Navigateur de schéma, puis sélectionner le schéma souhaité.
J'ai essayé les deux options suggérées par Michael Munsey et fonctionne pour moi.
Je voulais fournir une autre option pour afficher les tables filtrées. Souris Cliquez avec le bouton droit de la souris sur le nœud de votre arbre, sélectionnez "Appliquer le filtre", cochez la case "Inclure les synonymes" et cliquez sur OK. Ça y est, vous devriez pouvoir voir les tables ici. Ça marche pour moi.
Courtesy: http://www.thatjeffsmith.com/archive/2013/03/why-cant-i-see-my-tables-in-Oracle-sql-developer/
Sélectionnez "Autres utilisateurs" dans le et sélectionnez votre utilisateur (schéma), sous lequel vous pourrez voir vos tables et vos vues.
J'ai le même problème dans sqlDeveloper64-3.0.4.34 et sqlDeveloper64-3.1.1.07.42.
Selon https://forums.Oracle.com/forums/thread.jspa?threadID=2202388 il semble qu'il y ait un bogue dans le pilote JDBC relatif à 'Out Of Band Breaks' - un niveau bas Problème TCP.
La solution de contournement est de lancer le développeur SQL avec la propriété JVM -Doracle.net.disableOob = trueJ'ai essayé cette solution pour les versions 3.0 et 3.1 et cela fonctionne.
Donc, je viens de citer ici la solution du forum:
Je pense avoir identifié la cause de ces problèmes pour certains utilisateurs et non pour d'autres. Il semble qu'il y ait un bogue dans le pilote JDBC lié à 'Out Of Band Breaks' - un problème de bas niveau TCP. Le bogue semble se manifester de plusieurs façons. Jusqu'à présent, j'ai identifié l'utilisation de connexions partagées (en particulier avec Vista ou Windows 7) et la connexion via VPN (tout système d'exploitation) comme scénarios courants. Dans tous les cas, ne pas avoir d'accès DBA est également un problème.
Tout d'abord, laissez-moi vous expliquer pourquoi l'accès DBA fait une différence. Lorsque nous accédons pour la première fois à une vue de dictionnaire de données particulière, nous essayons d’abord de voir si nous pouvons avoir accès à la version DBA de la vue (ou si certains cas sont tab $, etc.). Ces vues sont beaucoup plus efficaces que les versions ordinaires de USER, nous voulons donc les utiliser si nous le pouvons. Nous vérifions uniquement chaque vue DBA une fois par session (et uniquement lorsque cela est nécessaire), mais nous pouvons vérifier l'accès à de nombreuses vues.
Le bogue OOB semble se soulever lorsque nous effectuons cette vérification. Nous devrions obtenir une réponse simple et agréable de la base de données. Toutefois, dans les scénarios où le bogue se produit, ce bogue réseau de bas niveau provoque une erreur qui place la connexion dans un état inutilisable. Il en résulte alors toutes les erreurs Connection Closed . Il semble y avoir une solution de contournement: le pilote JDBC prend en charge la désactivation de la fonction OOB. Cependant, cela affectera la possibilité d'annuler une instruction d'exécution. Je ne vous recommanderais donc pas d'utiliser la solution de contournement en général, mais cela devrait résoudre le problème dans les situations où les utilisateurs rencontrent ce problème spécifique.
Pour activer la solution de contournement, vous devez définir une propriété du système Java - Oracle.net.disableOob = true. Vous pouvez définir cela de deux manières. La première consiste à le transmettre sur la ligne de commande en tant que sqldeveloper -J-Doracle.net.disableOob = true. Bien sûr, cela ne fonctionne que si vous exécutez normalement à partir de la ligne de commande. Vous pouvez également ajouter une ligne au fichier sqldeveloper.conf (situé sous + sqldeveloper\bin +). Là, la ligne serait AddVMOption -Doracle.net.disableOob = true
Nous étudions d'autres solutions, mais pour le moment, la solution de contournement devrait vous permettre de travailler avec SQL Developer.
- John
Équipe de développeurs SQL
Vous n'avez probablement pas accès à l'une des méta-tables interrogées par SQL Developer 3. Si j'ai choisi la bonne requête, il exécute l'instruction SELECT suivante:
select * from (
SELECT o.OBJECT_NAME, o.OBJECT_ID ,'' short_name, decode(bitand(t.property, 32), 32, 'YES', 'NO') partitioned,
decode(bitand(t.property, 64), 64, 'IOT',
decode(bitand(t.property, 512), 512, 'IOT_OVERFLOW',
decode(bitand(t.flags, 536870912), 536870912, 'IOT_MAPPING', null))) iot_type,
o.OWNER OBJECT_OWNER, o.CREATED, o.LAST_DDL_TIME, O.GENERATED, O.TEMPORARY, case when xt.obj# is null then 'N' else 'Y' end EXTERNAL
FROM SYS.Dba_OBJECTS O ,sys.tab$ t, sys.external_tab$ xt
WHERE O.OWNER = :SCHEMA
and o.object_id = t.obj#(+)
and o.object_id = xt.obj#(+)
AND O.OBJECT_TYPE = 'TABLE'
union all
SELECT OBJECT_NAME, OBJECT_ID , syn.SYNONYM_NAME short_NAME, decode(bitand(t.property, 32), 32, 'YES', 'NO') partitioned,
decode(bitand(t.property, 64), 64, 'IOT',
decode(bitand(t.property, 512), 512, 'IOT_OVERFLOW',
decode(bitand(t.flags, 536870912), 536870912, 'IOT_MAPPING', null))) iot_type,
SYN.TABLE_OWNER OBJECT_OWNER, o.CREATED, o.LAST_DDL_TIME, O.GENERATED, O.TEMPORARY, case when xt.obj# is null then 'N' else 'Y' end EXTERNAL
FROM SYS.Dba_OBJECTS O, sys.user_synonyms syn,sys.tab$ t, sys.external_tab$ xt
WHERE syn.table_owner = o.owner
and syn.TABLE_NAME = o.object_NAME
and o.object_id = t.obj#
and o.object_id = xt.obj#(+)
and o.object_type = 'TABLE'
and :INCLUDE_SYNS = 1
)
where /**/object_name not in (select object_name from recyclebin)
AND not object_name like 'BIN$%'
Essayez d'exécuter cette instruction pour obtenir un message d'erreur complet indiquant quelle table n'existe pas (ce qui équivaut à "n'est pas visible en raison de droits d'accès manquants"). Le développeur SQL demandera des valeurs pour SCHEMA et INCLUDE_SYNS. Définissez SCHEMA sur votre nom d’utilisateur et INCLUDE_SYNS sur 0.
SQL Developer 1.1 a probablement utilisé une requête plus simple fonctionnant avec vos droits d'accès.
La réponse à propos de passer sous "Autres utilisateurs" était proche, mais pas assez explicite, j'ai donc ressenti le besoin d'ajouter cette réponse ci-dessous.
Dans Oracle, seules les tables appartenant à des schémas (bases de données dans MS SQL Server) appartenant au compte auquel vous êtes connecté s'affichent. Si le compte ne possède/n'a rien créé, vous ne verrez rien, même si vous avez des droits/permissions sur tout ce qui se trouve dans la base de données! (Ceci est contraire à MS SQL Server Management Studio, où vous pouvez voir tout ce sur quoi vous avez des droits et le propriétaire est toujours "dbo", à moins qu'un administrateur n'entre et le change pour une raison imprévisible.)
Le propriétaire sera le seul à voir ces tables sous "Tables" dans l'arborescence. Si vous ne les voyez pas parce que vous n'êtes pas leur propriétaire, vous devrez aller sous "Autres utilisateurs" et développer chaque utilisateur jusqu'à ce que vous sachiez qui a créé/possède ce schéma, si vous ne le connaissez pas déjà. Peu importe que votre compte ait ou non des autorisations sur les tables, vous devez toujours aller sous "Autres utilisateurs" et trouver cet utilisateur qui le possède pour le voir, sous "Tables"!
Une chose qui peut vous aider: lorsque vous écrivez des requêtes, vous spécifiez en fait dans la nomenclature qui est ce propriétaire, ex.
Select * from admin.mytable
indique que "admin" est l'utilisateur qui en est le propriétaire, vous devez donc aller sous "Autres utilisateurs> Admin" et développer "Tables" et voilà.
J'ai eu ce problème sur mon Mac . Je l'ai corrigé en le désinstallant ET en supprimant le dossier /Users/aa77686/.sqldeveloper . La désinstallation sans suppression de ce dossier ne l'a pas corrigé.
Ensuite, re-téléchargé et réinstallé.
Lancé, ajouté des connexions et cela a bien fonctionné.
Quittez-le, redémarrez-le plusieurs fois et affiche les tables, etc. correctement jusqu’à présent.
accordez select sur sys.external_tab $ à [myUser]; travaillé pour moi . merci Codo
3.1 n'avait pas d'importance pour moi.
Cela m'a pris un certain temps, mais j'ai réussi à trouver la version 2.1 pour l'essayer ici: http://www.Oracle.com/technetwork/testcontent/index21-ea1-095147.html
1.2 http://www.Oracle.com/technetwork/testcontent/index-archive12-101280.html
Cela ne fonctionne pas non plus, toujours pas de tables, donc cela ressemble à quelque chose avec la permission.
L'identité utilisée pour créer la connexion définit les tables que vous pouvez voir dans Oracle. Avez-vous fourni des informations d'identification différentes lors de la configuration de la connexion pour la nouvelle version?
SQL Developer 3.1 résout ce problème. C'est une version à adopter tôt pour le moment cependant.
Pour moi, cela a fini par être un problème d'autorisations.
J'ai résolu le problème en créant un rôle de superutilisateur (CREATE ROLE root WITH SUPERUSER LOGIN PASSWORD 'XXXXX';), puis en utilisant ce compte de superutilisateur pour se connecter à la base de données.
Ce ne sera évidemment pas une solution viable dans toutes les situations.