Discussion :

[alf_idsoft]

Bonjour,

Il m'arrive un soucis assez curieux lié à une réorganisation de la base de donnée par le DBA, notamment les tablespace.
L'environnement sur lequel je travaille présente plusieurs particularités et en attendant une possible ré-écriture, il faut faire avec.
- le schéma INFO est le propriétaire de toutes les tables et indexes dans Oracle, il a quasi tous les droits
- les requêtes dans Delphi sont faites de ce genre : "select * from [schema].table" où [schema] est remplacé avant l'exécution par INFO
- la plupart des écrans travaillent sur des tables paradox temporaires issues des tables Oracle

Aujourd'hui, les utilisateurs n'ont pas de soucis, le programme fonctionne normalement pour eux. Par contre à l'informatique, on se connecte en INFO et dans certains cas, on a des plantages : "la table n'est pas indexée".
Une procédure commune créée les tables temporaires Paradox à partir des tables Oracle : on ajoute les champs et les indexes avant de faire un tableParadox.Create.
En passant en debug, je vois à quel endroit il y a le problème :
- en utilisateur normal, tableOracle.indexdefs.count est > 0
- en utilisateur INFO, tableOracle.indexdefs.count = 0 !!! donc la table Paradox n'a pas d'index donc elle plante à sa création.

Je n'arrive pas à comprendre pourquoi le "superutilisateur" et propriétaire n'arrive pas toujours à voir ses propres indexes, quelle subtilité il peut y avoir derrière ttable.indexdefs ?

Avant que les tablespace soient réorganisés, on n'avait pas le problème. Mais comme cela ne touche pas les utilisateurs, on ne s'est pas rendu compte tout de suite.

Dans un autre programme, c'est carrément vicieux : en utilisateur normal, un locate se place sur le enregistrement, et en INFO, non ! mais sans plantage, le locate ramenant true...

Si vous avez des idées, je suis preneur car là, je rame et dur de trouver quelquechose sur le net

[ShaiLeTroll]

Cela dépendre du propriétaire du schema
C'est assez complexe Oracle à ce sujet
Possible que les indexes soient gérés par utilisateur au lieu d'être globalisé au schema, moi j'ai utilisé Oracle qu'une seule fois, j'ai eu assez de mal avec ! je faisais tout avec un seul utilisateur (celui de l'appli) même scott tiger ne fonctionnait plus, le dev dont je reprenais la maintenance n'avait rien laissé comme documentation (mdp perdu, ça c'est du professionnalisme !)

Faudra voir avec les spécialistes Oracle
Avec SQL*Plus ou TOAD, arrives-tu à voir la même chose ?

Sinon, des tables temporaires Paradox ???
Est-ce vraiment plus rapide qu'un accès à Oracle ?

Pour le locate, la seule fois où je l'ai vu 'planté' en renvoyant true mais sur le mauvais enreg, c'était avec Paradox avec un Filter actif plus un locate, là il n'aimait pas du tout !

[alf_idsoft]

Merci de ta réponse

Il y a des propriétaires de schéma en Oracle ??
J'ai beau utiliser Oracle depuis des années, utiliser quelques fonctions DBA, c'est du genre complexe... Ajouté à cela une gestion chez nous un peu farfelue des droits d'accès par schéma et par groupe, du paradox, et ça met un beau bazar.
Pour les gens d'Oracle, c'est un problème lié à Delphi et je suis plutôt d'accord car on n'a aucun problème sur Toad : je passe mes journées à faire des requêtes, connecté en INFO et tout a toujours bien fonctionné, c'est un détail qui coince au niveau de Delphi...
Paradox, c'est une manière de fonctionner avec des données temporaires, c'est périmé : les écrans que j'ai créés, j'ai mis un clientdataset et pas d'embrouille, ni de stockage des tables (on fonctionne en terminal serveur) ni en performance (rien de + rapide)

[alf_idsoft]

Trouvé dans l'aide Delphi :

IndexDefs est une collection de définitions d'index,chaque entrée définissant un index disponible de la table.A la conception,spécifiez les définitions d'index d'une table avant d'appeler CreateTable ou de créer une table.

Généralement,une application accède ou spécifie les index àl'exécution en utilisant les propriétés IndexFieldNames ou IndexFields.

Si IndexDefs est mis àjour ou modifiémanuellement,la propriétéStoreDefs prend la valeur true.

Remarque*: Les définitions d'index de la propriétéIndexDefs peuvent ne pas refléter exactement les index utilisables d'une table.Avant d'examiner IndexDefs,appelez sa méthode Update pour actualiser la liste des définitions d'index.

Donc, un peu comme recordcount, IndexDefs n'est pas fiable.
J'ai fait un tableOracle.IndexDefs.update, la conséquence est que l'erreur change : Au lieu de "la table n'est pas indexée", j'ai : [table Paradox] : Pas d'index pour le champs XXX (champs indexé dans la table Oracle)
Je tourne autour mais ça bloque toujours...

[e-ric]

Sinon, des tables temporaires Paradox ???
Est-ce vraiment plus rapide qu'un accès à Oracle ?

C'est peut-être tout simplement pour limiter les accès à Oracle (coût de licence, surcharge du serveur)

Pour éviter au mieux les problèmes, il vaut mieux s'en tenir aux caractéristiques communes aux 2 SGBDs, du point de vue de la VCL. Si, si, il y en a...

Remarque au sujet de Toad, c'est écrit en Delphi... mais en utilisant les API d'Oracle directement si je me souviens bien.

Est-ce que le code de récupération des métadonnées et des données est parfaitement au point ? En outre, si tu accède à Oracle via le BDE, as-tu vérifié la propriété USER NAME dans la définition de ton alias ? Il me semble que c'est cette propriété qui permet de choisir le propriétaire.

Cdlt

[ShaiLeTroll]

C'est peut-être tout simplement pour limiter les accès à Oracle (coût de licence, surcharge du serveur)

Oui, j'avais penser à la même chose, un stockage local de requête un peu lourde pour réduire le trafic réseau mais autant partir sur un SQLite ou MySQL Embedded qui seront plus performant et dont le SQL est plus proche de celui d'Oracle que celui de Paradox sans parler du déploiement du BDE

caractéristiques communes aux 2 SGBDs, du point de vue de la VCL.

Open et Close

Faudrait voir ce que donne ADO ou DBExpress à ce sujet, voire même FireDAC

Toad, c'est écrit en Delphi... mais en utilisant les API d'Oracle directement si je me souviens bien.

Il me semble que c'est bien cela, Toad Oracle en Delphi doit utiliser les trucs genre OCI, Toad MS lui c'est du .NET

[alf_idsoft]

Ceux qui ont créé le code ne sont plus là pour se justifier, mais je pense que c'est le moyen le plus simple qu'ils ont trouvé pour utiliser des données temporaires, au lieu d'un clientdataset.
Il y a 12-14 ans, on n'avait pas de sql lite ou autre équivalent, enfin je crois pas...

Aaaah, le username dans le BDE... tiens tiens... non, ce n'est pas le même ! Mais dans la base de dev non plus et pourtant, cela fonctionne. Mais en fait, quand on se connecte, cela met le username qu'on a saisit.

J'ai ptete tort mais pour moi, c'est lié au changement de configuration des tablespaces. Pour Oracle, c'est un problème Delphi et pour Delphi, c'est un problème Oracle.... Les tablespaces ne sont pas les mêmes entre la base de prod et la base de dev, et le seul user pour lequel il y a des problèmes, c'est le propriétaire des objets en prod

[ShaiLeTroll]

Mais en fait, quand on se connecte, cela met le username qu'on a saisit.

Qui saisi ?
L'utilisateur final ? tu as autant de compte DB que d'utilisateur de ton appli ?
En général, je sépare, l'application a ses propres utilisateurs internes regroupés par thème applicatif et criticité du code.
D'ailleurs, j'espère passer vers un vrai modèle 3-tiers, le client Delphi ou le client Mobile\Web HTML+JS ou même un programme tiers en COM ou WS ne se connecte plus du tout à la DB mais au serveur applicatif DataSnap qui fait le boulot et emet ce qu'il faut en retour

la gestion du login de l'utilisateur final est stocké dans la DB ou via LDAP (indépendant ou celui de AD de la session windows), les droits applicatifs étant géré par le logiciel et non par les droits sur la DB

au lieu d'un clientdataset.

Oui qu'il n'est pas forcément plus performant à grand volume

Il y a 12-14 ans

, oui genre époque de D4-D6, à peine le début de DBX qui n'était pas engageant face à la simplicité du BDE

lié au changement de configuration des tablespaces.

Lors que je t'ai répondu, j'allais le mentionné suite à une recherche google mais comme cela semblait lié au stockage, je l'avais écarté de ma réponse

Pour Oracle, c'est un problème Delphi et pour Delphi, c'est un problème Oracle....

Qui as-tu donc contacté ? genre le Quality Central ?
C'est surtout que ce soit l'un ou l'autre, fait un contrat de maintenance (payant) pour qu'ils étudient un cas de ce genre

[alf_idsoft]

Il y a une centaine d'utilisateur, chacun se connecte avec son identifiant. Les requêtes sont toutes exécutées avec le schéma INFO, vu qu'il est le propriétaire.
L'équipe actuelle n'est pas forcément très d'accord avec la façon dont les anciens ont codé, mais cela fonctionne depuis des années, alors on a laissé car on doit répondre aux attentes.
Nous ne sommes pas dans une grosse structure donc la gestion des droits telle qu'elle est, même si elle est un peu spéciale, nous suffit. Le jour où on ré-développe l'application entièrement, ce sera bien différent.

Donc l'utilisateur se connecte avec son login = le username du database général. C'est un utilisateur oracle qui n'existe nulle part ailleurs.


Le clientdataset, je n'ai jamais fait de test pour savoir s'il est plus performant mais à aucun moment je n'hésiterai par rapport à une table paradox et ses nombreuses limitations (nombre de colonnes, types différents, répertoire de travail sur le disque, plantage de la table d'index....).


Je dois reparler du problème avec le DBA. Jusqu'à maintenant, avec une base qui fonctionne très bien, à partir du moment où j'ai eu un problème dans Delphi, cela ne pouvait jamais venir d'Oracle. En dehors du DBA et de ce forum Delphi, je ne sais pas à qui m'adresser...


Depuis l'autre jour, je peux apporter des précisions :
Je lance mon appli en INFO, un écran qui fonctionne, je mets un point d'arrêt juste après le OPEN et je regarde le Table.indexdefs.count : 0. Pourtant, c'est une grosse table et tout va bien.
Je relance l'appli en utilisateur "normal", même opération, Table.indexdefs.count : 9. Aucune différence dans le fonctionnement.
Pas de plantage car dans cet écran, pas de création de table Paradox à partir de la table principale de l'écran.
Donc, pour toutes les tables, je perds mes indexes dans Delphi si je suis connecté en INFO en prod, et uniquement dans ce cas de figure.

Je vois que tout le monde a un tablespace par défaut à USERS, mais INFO a un tablespace par défaut particulier (et qui est logique)
En base de dev, tout le monde a le même tablespace par défaut, un qui n'existe plus d'ailleurs. Et là, tout marche, même en INFO.
Ces infos sortent complètement du cadre Delphi.
Moi, mon problème et que Delphi ne trouve pas les indexes des tables indexées si on est connecté en INFO, qui en est le propriétaire...