You might create an on connect trigger that trows an exception on certain condition, for example the value of a generator (bcause this gets visible to every transaction immediately) and for other users than yourself. That will prevent applcication from reconnecting successfully.
Am 20.05.2014 22:18, schrieb Markov Dmitri markovdmi...@yahoo.com [firebird-support]: > > > It's not resolve problem, because any my application can reconnect to > database. > > 20.05.2014 23:45, 'liviusliv...@poczta.onet.pl' > liviusliv...@poczta.onet.pl [firebird-support] пишет: >> >> >> Hi, >> >> Delete from mon$attachments excluding current connection >> After that you are only logged user >> >> Regards, >> Karol Bieniaszewski >> >> ----- Reply message ----- >> Od: "Markov Dmitri markovdmi...@yahoo.com [firebird-support]" >> <firebird-support@yahoogroups.com> >> Do: <firebird-support@yahoogroups.com> >> Temat: [firebird-support] Re: database became broken for any reasons >> Data: wt., maj 20, 2014 20:22 >> >> >> >> >> I turn off automatic sweep - only manual sweep. >> For today I try to change keepalive parameters - it's look like all >> ok. All processes named fb_inet_server.exe closed, but it's work if >> connection was lost. It's not work when the connection established and >> not closed for any reasons(for example the application waiting for >> some system process on client side and so don't close connection and >> don't react on my commands from server side). >> So how I can from server side close connection normally, so after that >> I may shutdown database and it's not create orphan records or pages? >> I use shutdown for absolute prohibition of connection to database >> using user accounts for database update process(changing metadata or >> changing only data). >> >> 20.05.2014 18:47, Ann Harrison aharri...@ibphoenix.com >> [firebird-support] пишет: >>> >>> On Mon, May 19, 2014 at 1:31 PM, markovdmi...@yahoo.com >>> <mailto:markovdmi...@yahoo.com> [firebird-support] >>> <firebird-support@yahoogroups.com >>> <mailto:firebird-support@yahoogroups.com>> wrote: >>> >>> >>> >>> For preventing orphan pages or backversions I turn off autosweep. >>> So for the last month I don't see any orphan pages or orphan >>> backversions. >>> >>> >>> Probably you were shutting the database down hard while a sweep was >>> active. >>> >>> >>> I know that shutdown during sweep can broke database, so I turn >>> off autosweep and do only manual sweep. >>> >>> >>> I've got to take exception to your statement. Shutdown during sweep >>> doesn't "break" the database. It leaves some >>> space (record or page) inaccessible, but, assuming you're running >>> with forced writes turned on, the database is not >>> corrupt. All the data is accessible and correct. >>> >>> >>> My service of database looks like this: >>> 1) try normally close all connections(all my applications get >>> commands for starting of autoclose procedure) >>> >>> OK >>> >>> 2) kill all terminal instance of my applications >>> >>> OK, though that will leave errors in the log - but you caused them, >>> so not a big deal. >>> >>> 3) shutdown database(my software use non root access, so it's >>> guarantee single user access) >>> >>> OK. >>> >>> 4) killing all processes fb_inet_server.exe >>> >>> Not OK. Once the connections are gone, the fb_inet_servers will >>> eventually stop, after they've written all their changes to disk. If >>> you kill them, there's a chance that, for example, an old record >>> version will have been removed and the page it was on will have been >>> written, but the older versions that are chained to that record will >>> not have been removed and their pages flushed to disk. Firebird uses >>> a technique called "careful write" to maintain on-disk consistency >>> without a separate log. Essentially that means that when new >>> "things" are created, the thing is created first, then pointer to it >>> follow. Conversely, when a "thing" is removed, all the pointers are >>> removed first, then the thing itself. When done correctly and >>> consistently, careful writes never leave broken pointers. However, >>> it can lead to lost space. For example, when a table needs a new >>> data page, Firebird looks for a free page - they're indicated on >>> pages called PageInformationPages or PIPs. When it finds a free page >>> on a PIP, Firebird marks the page as "in use", before it starts the >>> process of allocating that page to the table, If the operation is >>> interrupted, the PIP will say that the page is in use, but it's not >>> part of a table or any other part of the database - hence, orphaned. >>> >>> Orphans are a normal and benign result of a hard database shutdown >>> with write pending. >>> >>> Good luck, >>> >>> Ann >>> >> > > -- Mit freundlichen Grüßen, Thomas Beckmann Diplom-Informatiker Wielandstraße 14c • 23558 Lübeck Tel +49 (22 25) 91 34 - 545 • Fax +49 (22 25) 91 34 - 604 Mail thomas.beckm...@assfinet.de <mailto:thomas.beckm...@assfinet.de> ASSFINET-Logo *ASSFINET Dienstleistungs-GmbH* Max-Planck-Straße 14 • 53501 Grafschaft bei Bonn i...@assfinet.de <mailto:i...@assfinet.de> • www.assfinet.de <http://www.assfinet.de/> Geschäftsführer: Dipl. Wirtschaftsinformatiker Marc Rindermann Registergericht Koblenz HRB 23331 Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
