Hallo,
mein Problem steht schon in der Überschrift.
Bisher habe ich die Felder immer über die Systemtabellen vergrößert.
Unter FB3 muss ja Alter Table Alter Column benutzt werden.

Das betreffende Feld wird aber in einem Trigger benutzt.

Und schon streikt FB3.
Ich müsste also erst den Trigger löschen, das Feld vergrößern und dann den Trigger wieder erzeugen.

Kennt jemand einen anderen, einfacheren Weg?

Trigger vorübergehend deaktivieren.

Hallo,
das ging nicht
Alter Trigger InActive ging nicht (irgendwas von in use).

Naja, der Trigger hat eine Aufgabe, die ist vielleicht wichtig.
Also muss man dafür sorgen, dass der oder die Clients nicht mehr auf die Tabelle zugreifen.
(Oder schaut nach irgendwelchen Leichen, die dem System vorgaukeln, dass es noch genutzt wird, alte Sessions, ..)
Wie das in FB administrativ gemacht wird, müsste ich allerdings selbst nachschauen.

markieren

Code:

gfix -shut single -force 0 <database>.fdb

Zitat von hoika:

Kennt jemand einen anderen, einfacheren Weg?

Neue Domain anlegen

markieren

Code:

ALTER TABLE YOUR_TABLENAME ALTER COLUMN YOUR_COLUMNAME TYPE YOUR_NEW_DOMAINNAME

Wenn man mir Domains arbeitet, kann man auch einfach die Domain verlängern:

markieren

Code:

ALTER DOMAIN YOUR_DOMAINNAME TYPE VARCHAR(NEW_SIZE)

Frank

Hm,
Markus,
was mache ich mit dem Befehl?
Das Problem hat ein Nutzer vor Ort,
der mit diesem Befehl (und dem Gegenstück) nichts anfangen soll.
Und ich habe ev. auch ein Mehrmandantensystem.

"Neue Domain": klingt gut, muss ich mal sehen, ob das wirklich so geht.

Der Befehl scheint dazu zu dienen, einen Fremdzugriff auszuschließen. Ist er abgesetzt, wäre die Bahn frei für Trigger löschen usw.
Der Klassiker ist ja, dass es ganz wichtige Nutzer gibt, die immer das Programm offen lassen, nicht gut für Updates.
Die Domains werden Dir wahrscheinlich nicht weiter helfen, weil Du sie dazu bereits an der Stelle verwenden müsstest.

Ansonsten:
Was erwartest Du? Und was sagt es uns, dass Du eventuell ein Mehrmandantensystem hast? > Du musst das Update mehrmals durchführen?!
Eine Modellaktualisierung aus der Ferne per Email oder so und keiner der sich drum kümmern muss/darf/kann? Ohne Remote Access geht es dann wohl nicht.

Moin, deaktivieren eines Triggers löscht keinerlei dependencies. In IBExpert gibt es ein spezielles Deaktivieren, das den kompletten quellcode des Triggers auskommentiert und den danach neu compiliert und somit dependencies auflöst. Ohne so was wie IBExpert bleibt eigentlich nur drop trigger, lter table, create trigger manuell machen (ob weitere Objekte zusätzlich betriffen sind, findet man in rdb$dependencies

Und falls wirklich jemand auf der db ein prepare statement mit genau dem Objekt hat (also der Table) und es dadurch ein "Object is use" Fehler gibt, dann kann man die Metadaten in IBExpert auch mit eine Einstellung in den Transaktionen (isc_tbp_wait statt default isc_tbp_nowait in den metadatentransaktionseinstellung der db registration, ob das in anderen tools auch geht weiss ich nicht, ich benutz keiner anderen Tools ) auch im laufenden Betrieb machen, gilt übirgens auch für fb25 sc und cs, fb3 ss ist da empfindlicher als fb25 ss.

Hallo,
vielen Dank an alle.

FB3-Support wird erst mal nach hinten geschoben