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 markovdmitri@...
[firebird-support]:

>
>
> It's not resolve problem, because any my application can reconnect to
> database.
>
> 20.05.2014 23:45, 'liviuslivius@...'
> liviuslivius@... [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 markovdmitri@... [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 aharrison@...
>> [firebird-support] пишет:
>>>
>>> On Mon, May 19, 2014 at 1:31 PM, markovdmitri@...
>>> <mailto:markovdmitri@...> [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.beckmann@... <mailto:thomas.beckmann@...>

ASSFINET-Logo

*ASSFINET Dienstleistungs-GmbH*
Max-Planck-Straße 14 • 53501 Grafschaft bei Bonn
info@... <mailto:info@...> • 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.