SQLMAnagerX 1.7.0.0

Romuald.besset

21/04/2004 à 09:19

Firetox wrote:

Bonjour, manu

j'ai besoin d'un peu d'aide

comment recuperer le shemla d'une table ou du moins est ce que sur oracle
ca existe comme sous SQLite : recuperer la chaine de creation de la table
avec les indexs
ca existe sous SQLite je vais voir sous MySQL et PostGreSQL

?? mysql : SHOW CREATE TABLE tbl_name

++ R&B

Firetox

21/04/2004 à 09:21

bonjour, R&B

oui je connais , ma question est ce que c'est comprehensible par oracle
cette syntaxe ?

"Romuald.besset" a écrit dans le message de
news: c656vu$81h$

Firetox wrote:
> Bonjour, manu
>
> j'ai besoin d'un peu d'aide
>
> comment recuperer le shemla d'une table ou du moins est ce que sur

oracle

> ca existe comme sous SQLite : recuperer la chaine de creation de la

table

> avec les indexs
> ca existe sous SQLite je vais voir sous MySQL et PostGreSQL

?? mysql : SHOW CREATE TABLE tbl_name

++ R&B

jacques trepp

21/04/2004 à 09:43

Roumegou wrote:

Christian a émis l'idée suivante :
Dans son message précédent, Roumegou a écrit :
jacques trepp avait prétendu :
Roumegou wrote:
ce serait l'équivalent du select from where into outfile toto.txt

C'est quoi cette commande ?
sous mysql, c'est accepté mais je ne trouve pas mon toto.txt ??

bonjour Eric,
ça permet d'exporter des données dans un fichier texte quelconque
(pourqoi pas toto.txt) :)
SELECT * FROM DOSBASE WHERE DOSSIER_KUNIK = 3 INTO OUTFILE
'D:nomadeDOSBASE.TXT';
ça me permet de générer du script dans le fichier que je veux, et
surtout, dans le répertoire qsue je veux.
on récupère par un :
LOAD DATA INFILE 'D:nomadeDOSBASE.TXT' INTO TABLE 'NomTable'

à bientôt

Salut Jacques
D'où mon intéret
mais je ne comprends pas. Je tape cette commande sous sqlyog et
impossible de trouver le fichier généré. (j'ai meme fait une rech
sur tout le disque). En plus je n'ai pas d'erreur.
select * from OPERATION into outfile 'c:RAD4usmonfichier.txt'
Par contre, si je refais une deuxième fois j'ai le msg File
'c:RAD4usmonfichier.txt' already exists
Donc je double les /
select * from OPERATION into outfile 'c:RAD4usmonfichier.txt'
et à la 2eme fois, j'ai le msg File 'c:RAD4usmonfichier.txt'
already exists
Et pourtant pas de trâces du fichier ????
Je crée un rep vierge, meme chose. Je ne comprends pas où il me
colle ce fichier ????

Bonsoir,

Chez moi cela marche...sur le disque "C" du serveur MySql bien sur...

Oups ! je suis fatigué ce soir
Faut que j'aille chercher ça sur mon serveur Linux.

Ben, justement. la commande :
SELECT * FROM DOSBASE WHERE DOSSIER_KUNIK = 3 INTO OUTFILE
'D:nomadeDOSBASE.TXT';
me crée bien le fichier DOSBASE.TXT dans le répertoire D:nomade.
Par contre, si tu n'indiques que le nom du fichier, il le met
systématiquement dans le répertoire du serveur Mysql.

j'ai trouvé ça dans le manuel mysql en français trouvé sur le site de MYsql
AB. http://www.mysql.com/
bonne journée.

--
Jacques TREPP
Albygest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.662 / Virus Database: 425 - Release Date: 20/04/2004

Roumegou wrote:

Christian a émis l'idée suivante :

Dans son message précédent, Roumegou a écrit :

jacques trepp avait prétendu :

Roumegou wrote:

ce serait l'équivalent du select from where into outfile toto.txt

C'est quoi cette commande ?
sous mysql, c'est accepté mais je ne trouve pas mon toto.txt ??

bonjour Eric,
ça permet d'exporter des données dans un fichier texte quelconque
(pourqoi pas toto.txt) :)
SELECT * FROM DOSBASE WHERE DOSSIER_KUNIK = 3 INTO OUTFILE
'D:\nomade\DOSBASE.TXT';
ça me permet de générer du script dans le fichier que je veux, et
surtout, dans le répertoire qsue je veux.
on récupère par un :
LOAD DATA INFILE 'D:\nomade\DOSBASE.TXT' INTO TABLE 'NomTable'

à bientôt

Salut Jacques
D'où mon intéret
mais je ne comprends pas. Je tape cette commande sous sqlyog et
impossible de trouver le fichier généré. (j'ai meme fait une rech
sur tout le disque). En plus je n'ai pas d'erreur.
select * from OPERATION into outfile 'c:RAD4usmonfichier.txt'
Par contre, si je refais une deuxième fois j'ai le msg File
'c:RAD4usmonfichier.txt' already exists
Donc je double les /
select * from OPERATION into outfile 'c:\RAD4us\monfichier.txt'
et à la 2eme fois, j'ai le msg File 'c:RAD4usmonfichier.txt'
already exists
Et pourtant pas de trâces du fichier ????
Je crée un rep vierge, meme chose. Je ne comprends pas où il me
colle ce fichier ????

Bonsoir,

Chez moi cela marche...sur le disque "C" du serveur MySql bien sur...

Oups ! je suis fatigué ce soir
Faut que j'aille chercher ça sur mon serveur Linux.

Ben, justement. la commande :
SELECT * FROM DOSBASE WHERE DOSSIER_KUNIK = 3 INTO OUTFILE
'D:\nomade\DOSBASE.TXT';
me crée bien le fichier DOSBASE.TXT dans le répertoire D:nomade.
Par contre, si tu n'indiques que le nom du fichier, il le met
systématiquement dans le répertoire du serveur Mysql.

j'ai trouvé ça dans le manuel mysql en français trouvé sur le site de MYsql
AB. http://www.mysql.com/
bonne journée.

--
Jacques TREPP
Albygest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.662 / Virus Database: 425 - Release Date: 20/04/2004

Vous avez filtré cet utilisateur ! Consultez son message

Roumegou wrote:

Christian a émis l'idée suivante :
Dans son message précédent, Roumegou a écrit :
jacques trepp avait prétendu :
Roumegou wrote:
ce serait l'équivalent du select from where into outfile toto.txt

C'est quoi cette commande ?
sous mysql, c'est accepté mais je ne trouve pas mon toto.txt ??

bonjour Eric,
ça permet d'exporter des données dans un fichier texte quelconque
(pourqoi pas toto.txt) :)
SELECT * FROM DOSBASE WHERE DOSSIER_KUNIK = 3 INTO OUTFILE
'D:nomadeDOSBASE.TXT';
ça me permet de générer du script dans le fichier que je veux, et
surtout, dans le répertoire qsue je veux.
on récupère par un :
LOAD DATA INFILE 'D:nomadeDOSBASE.TXT' INTO TABLE 'NomTable'

à bientôt

Salut Jacques
D'où mon intéret
mais je ne comprends pas. Je tape cette commande sous sqlyog et
impossible de trouver le fichier généré. (j'ai meme fait une rech
sur tout le disque). En plus je n'ai pas d'erreur.
select * from OPERATION into outfile 'c:RAD4usmonfichier.txt'
Par contre, si je refais une deuxième fois j'ai le msg File
'c:RAD4usmonfichier.txt' already exists
Donc je double les /
select * from OPERATION into outfile 'c:RAD4usmonfichier.txt'
et à la 2eme fois, j'ai le msg File 'c:RAD4usmonfichier.txt'
already exists
Et pourtant pas de trâces du fichier ????
Je crée un rep vierge, meme chose. Je ne comprends pas où il me
colle ce fichier ????

Bonsoir,

Chez moi cela marche...sur le disque "C" du serveur MySql bien sur...

Oups ! je suis fatigué ce soir
Faut que j'aille chercher ça sur mon serveur Linux.

Ben, justement. la commande :
SELECT * FROM DOSBASE WHERE DOSSIER_KUNIK = 3 INTO OUTFILE
'D:nomadeDOSBASE.TXT';
me crée bien le fichier DOSBASE.TXT dans le répertoire D:nomade.
Par contre, si tu n'indiques que le nom du fichier, il le met
systématiquement dans le répertoire du serveur Mysql.

j'ai trouvé ça dans le manuel mysql en français trouvé sur le site de MYsql
AB. http://www.mysql.com/
bonne journée.

--
Jacques TREPP
Albygest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.662 / Virus Database: 425 - Release Date: 20/04/2004

jacques trepp

21/04/2004 à 09:46

Firetox wrote:

Bonjour, manu

j'ai besoin d'un peu d'aide

comment recuperer le shemla d'une table ou du moins est ce que sur
oracle ca existe comme sous SQLite : recuperer la chaine de creation
de la table avec les indexs
ca existe sous SQLite je vais voir sous MySQL et PostGreSQL

sous MYSQL : g_requete = "SHOW CREATE TABLE "+nom_table donne le script de
création de la table, y compris en innoDB.

--
Jacques TREPP
Albygest

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.662 / Virus Database: 425 - Release Date: 20/04/2004

Manu

21/04/2004 à 10:08

> j'ai besoin d'un peu d'aide

comment recuperer le shemla d'une table ou du moins est ce que sur
oracle ca existe comme sous SQLite : recuperer la chaine de creation
de la table avec les indexs
ca existe sous SQLite je vais voir sous MySQL et PostGreSQL

J'en arrive a ma petite question : pourquoi ne pas avoir des méthodes dans
chaque accès natif concernant les métadatas ?
- d'une part, car c'est actuellement dans SQLManagerX que tu recherche les
infos sur les tables,
- d'autre part, cela existe en partie dans cGestionSQL

Cela permettrait vraiement d'avoir le fonctionnement
- accès natif - SQLManagerX pour SQLManagerX
- accès natif - cGestionSQL pour les requetes (avec un pont possible vers
SQLManagerX)

Inconvénient, il faut uniformiser a tout prix les méthodes qui rentre en
jeu.

Sinon sous Oracle, tu vas devoir te taper le boulot à la main à partir des
données des tables all_tab_columns :-(

--
Emmanuel

Firetox

21/04/2004 à 10:26

Mon probleme n'est pas tant le CREATE TABLE
maisplutot les index des table

la methode fonctionne sour SQLite, MySQL, PosTGReSQL
reste plus que Oracle pour les index

voici commen,t j'ai pense ca:
SQLManagerX prend 2 nouveaux membres

ShemaTable : la chaine CREATE TABLE
ShemaIndex : LA CHAINE CREATE INDEX

je part du principe comme SQLManagerX connait la struture de la table, il
doit etre capable de refaire le create : jusque la pas de souci. reste les
index : SQLite pas de souci car il stocke egalement quelque part le CREATE
INDEX, pour MySQL aussi avec un SHOW INDEX FROM nomtable et on a tout ce
qu'on veut il suffit de refaire les chaine CREATE INDEX

pour ORACLE et ADO je vais passe par SQLManagerX qui connait toutes les
colonnes, leur typer etc ... donc facile de refaire le CREATE TABLE
mais je ne connais rien sur les index d'une table (a part la PRIMARY KEY)

voila , j'en suis la
mes test sont très concluant avec SQLite car je met les ligne de creation de
la table et index si dans SQLDump on demande le DROP. avec biensur un DROP
table avant le tout

Voila
Bon dev
@+

"Manu" a écrit dans le message de news:
c658i7$8h9$

> j'ai besoin d'un peu d'aide
>
> comment recuperer le shemla d'une table ou du moins est ce que sur
> oracle ca existe comme sous SQLite : recuperer la chaine de creation
> de la table avec les indexs
> ca existe sous SQLite je vais voir sous MySQL et PostGreSQL

J'en arrive a ma petite question : pourquoi ne pas avoir des méthodes dans
chaque accès natif concernant les métadatas ?
- d'une part, car c'est actuellement dans SQLManagerX que tu recherche les
infos sur les tables,
- d'autre part, cela existe en partie dans cGestionSQL

Cela permettrait vraiement d'avoir le fonctionnement
- accès natif - SQLManagerX pour SQLManagerX
- accès natif - cGestionSQL pour les requetes (avec un pont possible vers
SQLManagerX)

Inconvénient, il faut uniformiser a tout prix les méthodes qui rentre en
jeu.

Sinon sous Oracle, tu vas devoir te taper le boulot à la main à partir des
données des tables all_tab_columns :-(

--
Emmanuel

Mon probleme n'est pas tant le CREATE TABLE
maisplutot les index des table

la methode fonctionne sour SQLite, MySQL, PosTGReSQL
reste plus que Oracle pour les index

voici commen,t j'ai pense ca:
SQLManagerX prend 2 nouveaux membres

ShemaTable : la chaine CREATE TABLE
ShemaIndex : LA CHAINE CREATE INDEX

je part du principe comme SQLManagerX connait la struture de la table, il
doit etre capable de refaire le create : jusque la pas de souci. reste les
index : SQLite pas de souci car il stocke egalement quelque part le CREATE
INDEX, pour MySQL aussi avec un SHOW INDEX FROM nomtable et on a tout ce
qu'on veut il suffit de refaire les chaine CREATE INDEX

pour ORACLE et ADO je vais passe par SQLManagerX qui connait toutes les
colonnes, leur typer etc ... donc facile de refaire le CREATE TABLE
mais je ne connais rien sur les index d'une table (a part la PRIMARY KEY)

voila , j'en suis la
mes test sont très concluant avec SQLite car je met les ligne de creation de
la table et index si dans SQLDump on demande le DROP. avec biensur un DROP
table avant le tout

Voila
Bon dev
@+

"Manu" <el@netcourrier.com> a écrit dans le message de news:
c658i7$8h9$1@reader1.imaginet.fr...

> j'ai besoin d'un peu d'aide
>
> comment recuperer le shemla d'une table ou du moins est ce que sur
> oracle ca existe comme sous SQLite : recuperer la chaine de creation
> de la table avec les indexs
> ca existe sous SQLite je vais voir sous MySQL et PostGreSQL

J'en arrive a ma petite question : pourquoi ne pas avoir des méthodes dans
chaque accès natif concernant les métadatas ?
- d'une part, car c'est actuellement dans SQLManagerX que tu recherche les
infos sur les tables,
- d'autre part, cela existe en partie dans cGestionSQL

Cela permettrait vraiement d'avoir le fonctionnement
- accès natif - SQLManagerX pour SQLManagerX
- accès natif - cGestionSQL pour les requetes (avec un pont possible vers
SQLManagerX)

Inconvénient, il faut uniformiser a tout prix les méthodes qui rentre en
jeu.

Sinon sous Oracle, tu vas devoir te taper le boulot à la main à partir des
données des tables all_tab_columns :-(

--
Emmanuel

Vous avez filtré cet utilisateur ! Consultez son message

Mon probleme n'est pas tant le CREATE TABLE
maisplutot les index des table

la methode fonctionne sour SQLite, MySQL, PosTGReSQL
reste plus que Oracle pour les index

voici commen,t j'ai pense ca:
SQLManagerX prend 2 nouveaux membres

ShemaTable : la chaine CREATE TABLE
ShemaIndex : LA CHAINE CREATE INDEX

je part du principe comme SQLManagerX connait la struture de la table, il
doit etre capable de refaire le create : jusque la pas de souci. reste les
index : SQLite pas de souci car il stocke egalement quelque part le CREATE
INDEX, pour MySQL aussi avec un SHOW INDEX FROM nomtable et on a tout ce
qu'on veut il suffit de refaire les chaine CREATE INDEX

pour ORACLE et ADO je vais passe par SQLManagerX qui connait toutes les
colonnes, leur typer etc ... donc facile de refaire le CREATE TABLE
mais je ne connais rien sur les index d'une table (a part la PRIMARY KEY)

voila , j'en suis la
mes test sont très concluant avec SQLite car je met les ligne de creation de
la table et index si dans SQLDump on demande le DROP. avec biensur un DROP
table avant le tout

Voila
Bon dev
@+

"Manu" a écrit dans le message de news:
c658i7$8h9$

> j'ai besoin d'un peu d'aide
>
> comment recuperer le shemla d'une table ou du moins est ce que sur
> oracle ca existe comme sous SQLite : recuperer la chaine de creation
> de la table avec les indexs
> ca existe sous SQLite je vais voir sous MySQL et PostGreSQL

J'en arrive a ma petite question : pourquoi ne pas avoir des méthodes dans
chaque accès natif concernant les métadatas ?
- d'une part, car c'est actuellement dans SQLManagerX que tu recherche les
infos sur les tables,
- d'autre part, cela existe en partie dans cGestionSQL

Cela permettrait vraiement d'avoir le fonctionnement
- accès natif - SQLManagerX pour SQLManagerX
- accès natif - cGestionSQL pour les requetes (avec un pont possible vers
SQLManagerX)

Inconvénient, il faut uniformiser a tout prix les méthodes qui rentre en
jeu.

Sinon sous Oracle, tu vas devoir te taper le boulot à la main à partir des
données des tables all_tab_columns :-(

--
Emmanuel

SQLMAnagerX 1.7.0.0

6 réponses

Veuillez sélectionner un problème