bonjour
comment faire un backup de le base?
Je souhaiterai un format de sortie de type Excel
Version imprimable
bonjour
comment faire un backup de le base?
Je souhaiterai un format de sortie de type Excel
Bonjour,
réponse simple : Gbak , NBackup
et non le format de sortie ne seras pas Excel (mais là s'agit-il de la Base que tu veux sous format excel ou d'un Table ?)
à ce second sujet , il est assez facile avec Flamerobin , d'extraire tout ou partie d'une table (via SQL) , et de sauvegarder le résultat dans un fichier CSV (donc facile à importer dans Excel)
J'ai besoin de backuper la base. J'ai utilisé gback mais le format de sortie n'est pas transférable vers une autre base. J'ai besoin d'un backup qui me permet de reporter le contenu de la base dans un autre serveur. les formats xls ou csv conviennet
Il y a "IB Data Pump" qui fait ça il me semble. C'est avec cet outil que (si ma mémoire est bonne) j'ai converti des bases de données Paradox en Interbase. Et il me semble qu'il y a une option pour ressortir les données au format CSV.
Mais effectivement, ça sauvegarde les tables, mais pas la base dans sa totalité.
Allez voir ici :
http://ibphoenix.com/download/tools/migration
FBExport devrait convenir
mais je n'appellerai pas ça un backup, mais un export plutôt
il y a aussi
http://ibphoenix.com/products/software/dbfile
sinon, il y a la réplication :
http://ibphoenix.com/products/software/ibreplicator
je plussoie :plusser: , la question portait à confusionCitation:
Envoyé par makowski
Cela étant, je ne connais pas à fond "Flamerobin" cité par SergioMaster, mais il est peut-être possible d'extraire des tables au format CSV avec. A titre personnel, j'utilise IBExpert pour passer d'Excel à Firebird/Interbase et réciproquement couramment (en XLS comme en CSV) ... mais, IBExpert n'est pas gratuit.
Pour revenir aux "DataPump", en fait, ils permettent de transférer des Bases de données d'un format à un autre, mais via la création de scripts SQL. Donc pour créer des tables CSV ? finalement, j'ai des doutes.
Pour ce qui est de l'export, +1 aussi. A titre tersonnel, chez moi, le backup c'est :
D'une simplicité enfantine ... mais ça ne change pas le format de la base. ;)Code:Copy <chemin source>/<fichier>.<extension> <chemin sauvegarde>/<fichier>.<extension>
à condition que personne ne soit connecté à la base à ce moment là et pendant la copie ...Citation:
Envoyé par Pierre GIRARD
Certes, mais ça peut être lancé en batch la nuit après arrêt des processus du serveur Firebird. ;)
je préfère un petit GBAK (ou nbackup) en batch carCitation:
Envoyé par Pierre GIRARD
1- Cela évite le problème des personnes connectées (dans un environnement réseau on est jamais sur a 100% : pc mal éteint+programmes non quittés ces utilisateurs sont sans gêne :roll:)
2- Gbak fait un petit nettoyage (sweep) en même temps
Et ils restent connectés même si sous Linux je faisCitation:
Envoyé par SergioMaster
ou si j'arrête les services FireBird sous Windows ?Code:/etc/init.d/firebird stop
Ça m'étonnerais un petit peu.
Après, tu n'as pas tord, il n'y a rien de mieux qu'un logiciel de backup adapté pour ce genre de chose ;) ... mais ma méthode fonctionne, et elle permet même de copier une base de donnée directement d'un serveur Windows à un serveur Linux avec un minimum de compétences, de temps et sans avoir à installer d'outils particulier ni dans l'environnement de départ, ni dans celui de destination. :D
ah mais , j'ai quand même un arrêt/backup/redémarrage dans mon batch ;)
pas besoinCitation:
Envoyé par Pierre GIRARD
il suffit d'utiliser nbackup ou son équivalent sql pour préparer le fichier de la base à la copie directe
http://www.firebirdsql.org/file/docu...ck-unlock.html
Je ne vois pas en quoi :
est plus simple et plus efficace que :Now copy/backup/zip the database file to your heart's content, with your own choice of tools. A simple file copy is also possible.Code:nbackup [-U <user> -P <password>] -L <database>
Code:nbackup [-U <user> -P <password>] -N <database>
Dans les deux cas, aucun risque de pertes de données, et les bases accédées par les utilisateurs 24h/24 7j/7 en FireBird ne doivent pas être très nombreuses. Mais bon, comme moi je suis le seul utilisateur de ma base ... je ne vois peut-être pas toutes les situations possibles. ;)Copier la base (avec ou sans ZIP)Code:/etc/init.d/firebird stop
Code:/etc/init.d/firebird start
ben, il y en a et surement plus que tu ne sembles le croireCitation:
Envoyé par Pierre GIRARD
et il n'y a pas que ce cas là
car si tu as plusieurs bases, ton arrêt du serveur pour sauvegarder une base, coupe l'accès à toutes les bases, c'est un peu dommage non ?
bref le lock est utile, clairement.
A 2h00 du matin ?Citation:
Envoyé par makowski
A 2h00 du matin ?Citation:
Envoyé par makowski
Bon, pour des usines Oracle, je suis d'accord avec toi. Mais, pour des bases de données de type FireBird ou Interbase, qui ne se composent la plupart du temps que d'un seul et unique fichier (ce qui n'est le cas ni de Oracle, ni de DB2, ni de ... la plupart des bases de données), les cas d'utilisation ne permettant pas un arrêt à heure fixe sont probablement assez marginales.
Après, on trouve de tout dans la nature, mais moi, je vais toujours au plus simple, au plus rapides et au plus pratiques. Mais encore une fois, je ne te donne par tort (je t'ai même ajouté un "+" pour lever tout doute), et dans certains cas, ta solution est absolument indispensable ... ce qui ne rend pas la mienne invalide dans un grand nombre de cas. ;)
tu sais , la sous-traitance et la délocalisation ça existe 8O pour un peu qu'une SGBD soit utilisée dans divers pays ....Citation:
Envoyé par Pierre GIRARD
et ni dis pas "c'est exceptionnel" je travaille pour une petite entreprise et une des BDD est relié à ses sous-traitants (INDE, TUNISIE<- là y presque pas de décalage)
on en est pas encore à couvrir tous les fuseaux horaires ;)
Maintenant un de nos objectifs est que nos clients puissent interroger les Stocks disponibles (ajoute alors USA,JAPON ....) on arrive vite a une utilisation 24h/24h