Firebird 2.0 Owner ändern

[Gruber_Hans_12345]

ich dachte mir, ich habe irgendwo mal gelesen, das man mit einem Backup/Restore nachträglich den OWNER einer Datenbank ändern kann ...

aber erstens klappt das nicht, und zweitens finde ich nichts mehr dazu.

bin ich zu blöd zum suchen, oder geht das irgendwie anderes?

[edit]sehe gerade, den owner der Datenbank hat er geändert, aber nicht den der Tabelle und co

[hoika]

Hallo,

Backup als alter Onwe/Sysdba
Restore als neuen Owner.


Heiko

[Gruber_Hans_12345]

ja, habs gerade gesehen, das er den Owner der Datenbank geändert hat, ich habe nur bei der Tabelle geschaut, und da steht nach wie vor SYSDBA drinnen

wie kann ich den Owner aller Tabellen, bzw. aller Elemente ändern?

(habe mir gedacht, das geht alles auf einmal)

[mkinzler]

Notfalls lagere die DB in eine Skript aus

[TBx]

Guck Dir doch mal den Vortrag von Thomas Steinmaurer Owner Migration The easy Way im IBExpertLive an.
Falls nicht bekannt, IBExpertLive wird automatisch bei der Installation von IBExpert mitinstalliert, wenn gewünscht.

Gruß

Thomas

[Gruber_Hans_12345]

Zitat:

Zitat von onlinekater

Guck Dir doch mal den Vortrag von Thomas Steinmaurer Owner Migration The easy Way im IBExpertLive an.
Falls nicht bekannt, IBExpertLive wird automatisch bei der Installation von IBExpert mitinstalliert, wenn gewünscht.

Gruß

Thomas

habe mir gestern das IBExpertLive runtergeladen und installiert und passwort angefordert aber entweder dauert die passwort anfrage dort sehr lange, oder da läuft was schief ...

[IBExpert]

Zitat:

Zitat von Gruber_Hans_12345

habe mir gestern das IBExpertLive runtergeladen und installiert und passwort angefordert aber entweder dauert die passwort anfrage dort sehr lange, oder da läuft was schief ...

jo, da lief was schief, müsste in der zwischenzeit aber angekommen sein oder?


IBExpert and Firebird 2.1 64 Bit Roadshow in Germany
10.-14.12.2007 Anmeldung http://www.ibexpert.com/roadshow

[ralfiii]

Zitat:

Zitat von Gruber_Hans_12345

ja, habs gerade gesehen, das er den Owner der Datenbank geändert hat, ich habe nur bei der Tabelle geschaut, und da steht nach wie vor SYSDBA drinnen
wie kann ich den Owner aller Tabellen, bzw. aller Elemente ändern?

Mal ne blöde Frage:

Was passiert wenn man das so lässt?
Welche Einschränkungen hat der neue Datenbank-Owner denn dann?

Ich hab genau das blöde Problem: Anwendung mit SysDba/masterkey-Datenbank entwickelt :oops: .
Jetzt passiert's machmal, dass Kunden irgendeine Software am Rechner haben (oder nachträglich installieren), die auch Firebird verwendet und das Sysdba-passwort verändert haben.
Über kurz oder lang muss ich unseren alten Designfehler nun ausbügeln und nun suche ich nach der besten Möglichkeit das zu tun, irgendwas das auch bei Updates von bestehenden Installationen möglichst wenig Aufwand für die Support-Leute darstellt.

[IBExpert]

Zitat:

Zitat von ralfiii

Was passiert wenn man das so lässt?
Welche Einschränkungen hat der neue Datenbank-Owner denn dann?

Ich hab genau das blöde Problem: Anwendung mit SysDba/masterkey-Datenbank entwickelt :oops: .
Jetzt passiert's machmal, dass Kunden irgendeine Software am Rechner haben (oder nachträglich installieren), die auch Firebird verwendet und das Sysdba-passwort verändert haben.
Über kurz oder lang muss ich unseren alten Designfehler nun ausbügeln und nun suche ich nach der besten Möglichkeit das zu tun, irgendwas das auch bei Updates von bestehenden Installationen möglichst wenig Aufwand für die Support-Leute darstellt.

das einfachste ist einfach eine eigene Firebird Instanz auf einem eigenen Port zu installieren, geht z.B. mit dem IBExpert Instanzmanager recht einfach.

Dann kannst du in solchen Fällen den Original Firebird Server so lassen wie er ist und bringst bei solchen Kunden deinen eigenen mit, dann kommt ihr euch nicht in die Quere

[alex517]

Hier ein Artikel zu dem Thema.

Von Thomas Steinmaurer ist das Freeware-Tool "FBOwnerMigrator".
Man muss sich aber bei ihm direkt per E-Mail melden.

alex

[IBExpert]

geht mit ibexpert besser und ohne Einschränkungen wegen Systemtabellenmanipulation:

1. tools-extract metadaten- alle objekte mit allen Daten und Blobs auswählen
2. am besten als seperate files starten
3. In ibe$start.sql den Usernamen ändern und ggf connection string anpassen
4. dann runme.all.sql ausführen und du hast eine strukturgleiche DB mit allen Daten, aber dem neuen Owner

geht auch per script über ibeblock Befehle, so das man das auch bei Kundendatenbanken automatisiert machen kann
(zwar nur in Vollversion, aber wenn das eine One Time Aktion ist, dann geht das auch mit der Trial)

[tsteinmaurer]

Hallo Holger,

mir ist klar, dass Du IBExpert, wann immer es geht, pusht *g*, aber mich würde interessieren, von welchen "Einschränkungen" du sprichst?


Thomas Steinmaurer

[IBExpert]

Zitat:

Zitat von tsteinmaurer

mir ist klar, dass Du IBExpert, wann immer es geht, pusht *g*, aber mich würde interessieren, von welchen "Einschränkungen" du sprichst?

von denen, die du in deinem Artikel selbst erwähnst: direkte Manipulation der Systemtabellen.
Lies doch mal selbst deinen Artikel http://www.iblogmanager.com/download...d_Firebird.pdf
Ich finde du machst da relativ viele direkte updates auf rdb$ Tabellen und wie du schon selbst sagst, kann dabei ein Fehler durchaus das Ende einer benutzbaren Datenbank sien.

Der Unterschied zum IBExpert Verfahren ist eben, das dort einmal die DB per Menü oder Kommandozeile extrahiert wird, dann der Username ersetzt wird, um dann anschliessend das Script wieder zu starten und die DB unter dem neuen User wieder erstellt wird, mit allen Metadatenobjekten und allen Daten in allen Tabelle. Das ist eben wesentlich einfacher als der in deinem Artikel beschriebene Weg und auch für Softwarehäuser bei Kundenrechnern unbeaufsichtigt möglich, ebenso kann man übrigens auch auf dem Wege den Character set ersetzen, was bei vielen Datenbanken noch immer nur mit character set none läuft.

[ralfiii]

Ich hab jetzt mal probehalber einfach in IBExpert über
Service/Backup Database
und dann
Service/Restore Database (mit neuem Benutzernamen)

gemacht.
Es scheint das Arbeiten mit der DB mit neuem Benutzernamen zu funktionieren.
(Wo) muss ich da mit Problemen rechnen?

Danke,
Ralf

[tsteinmaurer]

Hallo Holger,

danke für den Link zu meinem Artikel. Den kenne ich. Schön, dass du meinen Blog liest. ;-)

Für mich stellt das keine Einschränkung dar, sondern vielmehr den Vorteil, dass man keine Daten transferieren muss. Ich weise immer nur darauf hin, Finger weg von den Systemtabellen, wenn man nicht weiß, was man tut. In diesem Fall weiß ich aber was ich tue. ;-)

Naja, IBExpert macht ja auch in bestimmten Situationen Updates auf Systemtabellen, aber ihr wißt ja auch, was ihr tuts.

Nix für ungut.


Thomas Steinmaurer

[IBExpert]

Zitat:

Zitat von tsteinmaurer

Hallo Holger,

danke für den Link zu meinem Artikel. Den kenne ich. Schön, dass du meinen Blog liest. ;-)

Für mich stellt das keine Einschränkung dar, sondern vielmehr den Vorteil, dass man keine Daten transferieren muss. Ich weise immer nur darauf hin, Finger weg von den Systemtabellen, wenn man nicht weiß, was man tut. In diesem Fall weiß ich aber was ich tue. ;-)

Naja, IBExpert macht ja auch in bestimmten Situationen Updates auf Systemtabellen, aber ihr wißt ja auch, was ihr tuts.

Nix für ungut.


Thomas Steinmaurer

ich seh ja wie fast immer unseren gemeinsamen Standpunkt: Wenn man keine Ahnung hat, besser Finger weg! :-)
Wer aber Ahnung hat kann auch durchaus mal mit dem Holzhammer kommen, machen wir, macht Ihr, warum nicht ...

Systemtabellen sind ja insgesamt keine heilige Kuh, daher kann man daran schon mal den einen oder anderen Trick
anwenden, aber ich hab schon mal Kundendatenbanken bekommen, bei denen 2 Stored Procedures den gleichen Namen hatten.
Funktionierte soweit ganz gut, sogar das Backup lief problemlos, nur das Restore brach sehr schnell ab.
Das hat der Kunde leider erst gemerkt, als er ca 9 Monate lang nur noch solche nicht benutzbare Backup Files hatte
und dringend auf ein funktionierendes angewiesen war. Wie diesre Fehler zustande kam weiss keiner, aber die Systemtabellen
waren inkonsistent und in diesem Falle hatte das sehr problematische Folgen. Infos wie man das vermeiden kann
bekommt man auch auf unserer Roadshow www.ibexpert.com/roadshow