Newsgroup: it.comp.lang.vo-clipper
Titolo: mysql

Scusate la banalità della domanda:
per copiare un database da un motore sql ad un altro (da un pc ad un altro
su entrambi installato mysql) ho spostato la cartella contenente tutti gli
archivi del mio database di prova  e sembra funzioni tutto (naturalmente non
ci sono policy di sicurezza), ma è veramente così semplice o c'è qualche
pericolo di perdita dati?
Ciao
Roberto

Io lo faccio in continuazione e non ho ancora perso niente. Certo non è il
massimo per la sicurezza ma pazienza....
Ciao.
                            Francesco Leo

 ha scritto nel messaggio
news:c39ni0$h89$1...@grillo.cs.interbusiness.it...



Si !!!   è così semplice...    Anche io faccio lo stesso da tempo.  Da un pò
di mesi lavoro con MySQL e VO
(coppia favolosa, insieme al "collante" delle librerie di Giluliani) e mi
sto facendo una idea su questo prodotto.
Lui ti fa fare molte cose in maniera semplice (come questa) ma ti mette a
disposizione anche gli strumenti per avere una sicurezza veramente ottima.
(leggi i vari testi e vedrai)
Ciao
Enio

 Enio
Qualcuno ha spostato le cartelle dei database MySql creati con tabelle
InnoDB relazionate con FOREIGN KEY? Il DB spostato funziona lo stesso? A me
non funziona piů niente, sono infatti costretto a fare il dump del db con
l'utility Mysqldump e reimportare i dati su un altro PC.
Ciao,
Piero
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 ha scritto nel messaggio
news:82Z51Z114Z124Y1...@usenet.libero.it...



Purtroppo Luigi, non al 100%.
Il backup parametrizzato tramite mysqldump che crea un file con
tutte le istruzioni DDL per la creazione del DB e l'inserimento
dei dati, funziona benissimo. Il restore invece, anche disattivando il
controllo dei vincoli e delle chiavi esterne,
deve essere lanciato 2, 3 volte ripristinare il db
correttamente.
Io nel file generato da mysqldump aggiungo in testa queste
righe:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS,
FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=NO_AUTO_VALUE_ON_ZERO */;
ed in coda:
/*!40101 SET SQL_MODE=@OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS */;
Se qualcuno ha dei suggerimenti, ben venga.
Ciao Piero.


 ha scritto nel messaggio
news:82Z51Z114Z124Y1...@usenet.libero.it...


Personalmente per la restore uso:
WorkDir()+[mysql --host=]+chost+[ --user=]+cUser+[ --password=]+cPassWord+[ 
--port=]+cPorta+;
    [ --quick ]+cDataBase+[ < "]+cPath+[/file.sql"]
Danilo Giuliani
www.softdevo.com
in...@softdevo.com
sup...@softdevo.com


Purtroppo se le tabelle sono del tipo InnoDb ed hanno delle
Foreign Key, il restore non funziona correttamente.
Es.
Tabella Figlio
-----------------------------------
Id
Id_padre (Foreign key di Padre(Id))
Tabella Padre
-----------------------------------
Id
Descrizione
Quando effettuo il dump del database il file generato
contiene i comandi per la creazione delle due tabelle e
fin qui tutto ok.
Quando effettuo il restore lui per prima cosa tenta di creare
la tabella Figlio, ma non essendoci quella del Padre a cui
è relazionata, genera un errore e prosegue.
