Discussion :

[YannOss]

Bonjour,
J'ai une base dont je ne peux changer les casts et qui contient une table avec une colonne castée en LONG.
Table:
T_Code--Varchar2
T_Text--Long

Je dois importer des données depuis un fichier Excel vers cette table, donc je créer une procédure qui 'en occupera:

Code :

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

1
2
3
4
Create or replace procedure Import (code varchar2,Text varchar2)
begin
insert into Table (T_Code, T_Text) values (code,Text)
end Import;

Malheureusement cette commande me lève, lors de la compilation, une erreur du genre:
erreur: PL/SQL: (ORA-00997):Utilisation interdite du type de données LONG

J'ai essayé de passé par une variable tampon:

Code :

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

1
2
3
4
5
6
7
8
9
Create or replace procedure Import (code varchar2,Text long)
as
ADDTEXT varchar2;
 
begin
cast (Text as varchar2);
ADDTEXT:=Text;
insert into Table (T_Code, T_Text) values (code,Text)
end Import;

L'erreur reste la même sur la ligne de la requête "insert into"... Pourriez vous m'indiquer mon erreur?

[Bibeleuh]

Tu ne fais pas d'erreur c'est juste que le type long c'est le mal :p
C'est un type très limité où l'on ne peut pas faire beaucoup d'opérations

En fait tu ne peux tout simplement pas insérer de long dans une table à partir de code PL / SQL , c'est uniquement faisable en Java, en C... ou grâce à la commande COPY en SQLPLUS.

Dans ton cas il faudrait normalement utiliser des CLOB , mais comme tu ne peux pas il faudrait que tu passe par un autre langage qui peut manipuler les long

[skuatamad]

En fait tu ne peux tout simplement pas insérer de long dans une table à partir de code PL / SQL

Et sans forcer des conversions implicites inutiles ça n'est pas mieux ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
SQL> create table t_imp (code varchar2(10),text long)
  2  /
 
Table created.
 
SQL> CREATE OR REPLACE procedure Import (p_code t_imp.code%TYPE, p_text t_imp.text%TYPE) as
  2  begin
  3    INSERT INTO t_imp (code, text) VALUES (p_code, p_text);
  4  end Import;
  5  /
 
Procedure created.
 
SQL> exec import('aa','jdfhjjqhgjlhqldfhghqfhqgjqhdfdfjhgjqghqjdfhg');
 
PL/SQL procedure successfully completed.
 
SQL> select * from t_imp
  2  /
 
CODE
----------
TEXT
--------------------------------------------------------------------------------
aa
jdfhjjqhgjlhqldfhghqfhqgjqhdfdfjhgjqghqjdfhg
 
 
SQL>

[Bibeleuh]

Et sans forcer des conversions implicites inutiles ça n'est pas mieux ?

En fait j'avais le même souci et après mes recherches désespérées j’en avais gardé la conclusion qu’il était impossible d’insérer un long. J’ai donc passé mon champ en CLOB.
Je n’ai même pas pensé une seule seconde à ta solution, j’aurai du venir sur le forum plus tôt

[Arkhena]

Bonjour,

Oracle préconise de ne plus utiliser de type LONG.

Do not create tables with LONG columns. Use LOB columns (CLOB, NCLOB, BLOB) instead. LONG columns are supported only for backward compatibility.

LONG columns store variable-length character strings containing up to 2 gigabytes -1, or 231-1 bytes. LONG columns have many of the characteristics of VARCHAR2 columns. You can use LONG columns to store long text strings. The length of LONG values may be limited by the memory available on your computer. LONG literals are formed as described for "Text Literals".

Oracle also recommends that you convert existing LONG columns to LOB columns. LOB columns are subject to far fewer restrictions than LONG columns. Further, LOB functionality is enhanced in every release, whereas LONG functionality has been static for several releases. See the modify_col_properties clause of ALTER TABLE and TO_LOB for more information on converting LONG columns to LOB.

(Source : http://docs.oracle.com/cd/E11882_01/...01.htm#i156865)

Ces types LONG vous poseront des problèmes si vous utilisez datapump...

Cordialement,

Arkhena

[YannOss]

Le coup de pas utiliser de LONG, moi, je l'ai bien compris c'est les créateurs du progociel dont je dois administrer les entrées-sorties qui ne sont apparemment pas au courant.
Bon en fait j'ai eu une intervention divine: mon code contenait un test de non égalité:

Code :

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

1
2
3
4
select T_Text  into Anctext from Table where T_Code=code;
If (Text <> Anctext) then
INSERT INTO TABLE (T_Code, T_Text) VALUES (code,Text);
end if;

En fait l'erreur était sur le Test '<>' dans le If. L'insert fonctionne parfaitement (en tout cas il ne lève pas d'erreur lors de la compilation)

J'avais fait ça pour éviter les textes en doublons. Mais en discutant avec le client, il a insisté sur le fait que le texte n'a JAMAIS été importé donc il ne pourrais y avoir de doublons.
Donc, je me suis arrangé pour être déchargé de la faute le cas échéant ^^

Quand tu ne peux affronter un obstacle, contournes le!

Mais à part ça je suis content de voir que le problème de suppression des LONG ne gène pas que moi, ils ont pas mal changé les habitudes en les supprimant, les gens de chez Oracle. Á leur place j'aurai créer une fonction qui convertit immédiatement toutes les colonnes LONG d'une table en VARCHAR2 dont la taille max serait la taille du LONG le plus long (sans mauvais jeu de mot)
Merci de votre attention. Et si par le plus grand des hasard vous connaissez une fonction qui a les attributs précisés ci-dessus vous gênez pas...