[OLEDB] Tout le code est sur une seule ligne

**randriano** · 11/06/2008, 14h33

Bonjour,

Je lance la requête de création de procédures et fonctions stockées sous un programme (avec le provider OleDb Oracle)!!! Ça marche très bien mais le problème c'est que le code (DDL) devient donc une seule ligne, c'est visible avec l'Oracle Enterprise Manager.

Ça fausse la procédure si elle contient un commentaire -- donc je dois passer par /* et */
Quelle est la raison de cela ? Cela complique beaucoup la lisibilité du code, est-ce que le retour à la ligne de Microsoft n'est pas aimé par Oracle ?

**orafrance** · 11/06/2008, 14h54

c'est probablement le programme client utilisé qui reformate le texte, il vaut mieux utiliser SQL*Plus.

**randriano** · 11/06/2008, 15h58

Je sais qu'en SQL*Plus ça va mais la base de données est utilisée par ce programme. La bizarrerie c'est que c'est normal avec le provider oledb de Microsoft mais en une ligne line pour celui d'Oracle !!
C'est pour ça que je me demande si ce provider n'aime pas les retours à la ligne venant d'un fichier sql

**DAB.cz** · 11/06/2008, 22h06

Ora OleDB n'accept pas CR LF correctement. C'était la raison j'ai abandonné OLEDB il y a deux années. Je n'ai pas vu la solution convenable.
Il y avais autres peines avec le provider de Microsoft (peut-être avec "returning into") ...

**randriano** · 12/06/2008, 08h45

Ora OleDB n'accepte pas CR LF correctement.

Qu'accepte-t-il alors ? CR seulement ou LF seulement
Quelle solution proposeriez-vous ?

Il y avais autres peines avec le provider de Microsoft (peut-être avec "returning into") ...

Je ne comprends pas

**randriano** · 13/06/2008, 12h11

Ce n'est pas du ressort d'oracle mais je me demande quel est le retour à la ligne sous Unix car CR LF est je crois celui de Microsoft non ?

**mnitu** · 13/06/2008, 16h43

Envoyé par randriano

Ce n'est pas du ressort d'oracle mais je me demande quel est le retour à la ligne sous Unix car CR LF est je crois celui de Microsoft non ?

LF

**DAB.cz** · 13/06/2008, 23h17

Envoyé par randriano

Qu'accepte-t-il alors ? CR seulement ou LF seulement
Quelle solution proposeriez-vous ?

Désolé, je n'ai pas trouvé la solution avec OraOLEDB. Est j'ai bien essayé.

Envoyé par randriano

Je ne comprends pas

Mon français...

Originalement, j'utilisais MSDAORA, mais je me suis heurté à quelques difficultés (je ne me rapelle plus les détails). Alors, j'ai examiné OraOLEDB - sans succès.

Ma solution - j'utilise OCI maintenant.

------------------------------------------

J'ai testé de nouveau - et voilà, ça marche!!!

Win XP, Ora10gR2 (OraOLEDB10.dll 10.2.0.1):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ORAConn.PerformDDL ('create or replace procedure aaaa is begin' + chr (13) + chr (10) + ' null; end;');

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
SQL> select line, text from user_source where name = 'AAAA' order by 1;
 
     LINE
---------
TEXT
-----------------------------------------------------------------------
        1
procedure aaaa is begin
 
        2
 null; end;

**randriano** · 16/06/2008, 09h01

C'est confirmé, c'est un bug de l'OleDB Oracle !!! J'ai remplacé les CRLF dans le fichier sql en CR puis en LF mais

!!

Merci DAB.cz pour le tuyau avec OCI mais je me dois d'utiliser cet outil de Ms (ADO). Je me demande, l'OleDB n'utilise-t-il pas OCI au fond, pourquoi ne gère-t-il pas donc CR et LF ?

**Vincent Rogier** · 16/06/2008, 09h19

Envoyé par randriano

l'OleDB n'utilise-t-il pas OCI au fond, pourquoi ne gère-t-il pas donc CR et LF ?

Envoyé par DAB.cz

Ma solution - j'utilise OCI maintenant.

Envoyé par DAB.cz

Il y avais autres peines avec le provider de Microsoft (peut-être avec "returning into") ...

99% des drivers ou frameworks d'accès à Oracle utilisent OCI.

Et bien souvent ces drivers parsent les ordres sql avant de les envoyer à Oracle via OCI (ne serait que pour parser les input binds). Et donc ces parsing peuvent être sources de soucis.

C'est pourquoi, par exemple, OCILIB ne preparse pas les requêtes (plus rapide et moins de source de bug)

Concernant le support de la fonctionnalité "returning into" d'oracle, très peu de drivers basé sur OCI la supporte (à ma connaissance, seul JDBC et OCILIB la supporte).

La clause sql "returning into" (extension Oracle) permet de renvoyer les lignes affectées par un insert, update, delete au sein de la même requête.
En gros, c'est un select des données modifiées est accolé à l'ordre sql initial et ce resulset renvoyé au client. Cela permet d'économiser des roundtrips avec les serveur.
De plus, cela est extrêmement intéressant pour les delete car tu peux ainsi récupérer les valeurs deletée. De plus, cela fonctionne aussi avec l'array interface....

**randriano** · 17/06/2008, 07h51

Est-ce que c'est moi où je sens que l'utilisation d'Oracle sous Windows n'est pas bon ménage.
Surtout avec les drivers OleDb qui doivent être normalement simple à utiliser

En fait, mais qu'utilise Sql*plus, OCI non ? Pourquoi j'ai un problème avec ado

**Vincent Rogier** · 17/06/2008, 09h07

Envoyé par randriano

Est-ce que c'est moi où je sens que l'utilisation d'Oracle sous Windows n'est pas bon ménage.
Surtout avec les drivers OleDb qui doivent être normalement simple à utiliser

En fait, mais qu'utilise Sql*plus, OCI non ? Pourquoi j'ai un problème avec ado

L'utilisation de Oracle sous Windows ne se limite pas à OLEDB !!!!

Sql*Plus utilise OCI...

Encore une fois, il faut dissocier la partie API client bas niveau (OCI) qui permet aux drivers "haut niveau" de fonctionner.

OCI est une API C disponible sur toute les plateformes supportées par Oracle (une quinzaine : Windows, linux, solaris, aix, up/ux, mac osx, openvms, zOS, ....)

TOUS les drivers "haut niveau" pour Oracle sont basés sur OCI (sauf le driver JDBC Thin et 2 drivers commerciaux qui eux 3 implémentent eux même la couche SQL*NET d'Oracle). Mais ces drivers ne possèdent pas la richesse d'OCI...

OCI est donc une api bas niveau ou sont manipulés pointeurs, ou on parle d'allocation mémoire, de callback, de tuning de connexion, ....
La plupart des fonctions OCI prennent une dizaine de paramètres qui sont tous des pointeurs, pointeurs de pointeurs..... Pour l'exemple, le code minimal pour se connecter à Oracle prend au moins 100 lignes de code !

Je reprend l'exemple d'OCILIB : le code source, sans compter les headers, fait 15.000 lignes. Tout ça dans le but d'avoir une interface plus simple et cacher la complexité d'OCI (sans pour autant perdre en performance).

Tu comprendras que donc les "wrappers" (les drivers haut niveau) sont une couche au dessus de OCI et donc disposent de leur propre code, spécificités et bugs...

OCI est aussi performant sous Windows que sous Unix (même si à l'origine Oracle n'était disponible que sous Unix).

Si tu as donc des soucis avec ADO, c'est que l'implémentation du driver ADO que tu utilises n'est pas parfaite, qu'elle n'implémente pas toute les fonctionnalité OCI, etc....

Les frameworks "généralistes" comme ADO, JDBC ont pour but d'apporter une interface unique qu'elle que soit le provider sous jacent..

C'est bien, générique, louable et certes pratique dans plein de cas.

Mais pourquoi, à ton avis, alors ces frameworks existent depuis 10-20 ans, beaucoup d'application sont codée aujourd'hui en OCI directement ? Car :

la généricité d'un framework n'intéresse pas tous le monde. Par exemple, dans ma boite, on bosse sous Oracle, exclusivement avec Oracle, c'est un choix.
la généricité d'un framework ne permet pas de bénéficier de la richesse et de certaines fonctionnalités d'un provider et comme OCI est l'API DB la plus large (Oracle11g : environ 1000 fonctions OCI !!) et la plus riche ... (tous SGBD confondu)..

Donc, en choisissant un framework comme ADO tu fais le choix d'une API unifiée, limitée par rapport aux fonctionnalités spécifique des providers et dont l'implémentation de l'API native peut elle même être une source de bugs.

Donc si tu n'es pas satisfait de ton driver OLEDB, choisit :

un autre driver OLEDB
un framework différent
une API native

Personnellement, bossant exclusivement avec Oracle, j'ai choisit de développer un driver non pas générique (eg : unifié pour les SGBD) mais un driver spécifique Oracle mais portable sur toute les plateformes Oracle et qui tends à exploiter toute la richesse des API natives Oracle.

**randriano** · 17/06/2008, 12h26

Premièrement, merci Vicenzo pour cette belle explication

Les frameworks "généralistes" comme ADO, JDBC ont pour but d'apporter une interface unique qu'elle que soit le provider sous jacent..

En effet, c'est pour cela que j'utilise ADO.
Je ne développe pas exclusivement pour Oracle !!! J'ai d'abord écrit le programme pour MySql, et maintenant il doit fonctionner aussi avec Oracle

**DAB.cz** · 17/06/2008, 22h19

Envoyé par DAB.cz

J'ai testé de nouveau - et voilà, ça marche!!!

Win XP, Ora10gR2 (OraOLEDB10.dll 10.2.0.1):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ORAConn.PerformDDL ('create or replace procedure aaaa is begin' + chr (13) + chr (10) + ' null; end;');

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
SQL> select line, text from user_source where name = 'AAAA' order by 1;
 
     LINE
---------
TEXT
-----------------------------------------------------------------------
        1
procedure aaaa is begin
 
        2
 null; end;

Le test a été réalisé 13.6.2008 utilisant ADO (alors je démens que la solutions n'existe pas) - quelles versions tu utilises?
(OraConn est mon "wrapper" sur ADO - ORAConn.PerformDDL = TADOConnection.Execute)

**DAB.cz** · 17/06/2008, 23h01

Envoyé par randriano

Premièrement, merci Vicenzo pour cette belle explication

je me joins

Envoyé par randriano

En effet, c'est pour cela que j'utilise ADO.
Je ne développe pas exclusivement pour Oracle !!! J'ai d'abord écrit le programme pour MySql, et maintenant il doit fonctionner aussi avec Oracle

Il existe des composants comprenant plusiers SGBD qui n'utilisent pas ADO. AnyDAC http://www.da-soft.com par ex. - mais c'est pour Delphi = pas convenable pour toi

.