Afterthought. If a disconnected user reconnects, does it use the previous record in MON$ATTACHMENTS, or create a new record? If the later, is there a way to force a re-connect rather than a new connection?

--- In firebird-support@yahoogroups.com, "homerjones1941" <homer@...> wrote:
>
> Thanks to everyone who responded. It sounds like I need to work with TCP/IP settings since settings in the .conf file could create more problems. Or, maybe I should just tell my users to stop doing things that makes Windows lock up :-)
>
> Thanks again for helping me.
>
>
>
> --- In firebird-support@yahoogroups.com, "homerjones1941" <homer@> wrote:
> >
> > Ok. Nobody wants to talk to me so I'll simplify.
> >
> > How can I force a refresh of MON$ATTACHMENTS from a Delphi application?
> >
> >
> > --- In firebird-support@yahoogroups.com, "homerjones1941" <homer@> wrote:
> > >
> > > Limiting the number of users has been discussed before, but I still have a couple of unanswered questions.
> > >
> > > We have a multi-user Delphi application with a Firebird 2.14 database. User access is controlled by the app, which connects using a single log in (not SYSDBA). The application limits the number of users (not connections) because the main app occasionally launches child apps which also connect.
> > >
> > > The methodology is, the app queries MON$ATTACHMENTS and counts connections for the main app, ignoring the children. We use the MON$REMOTE_PROCESS field to distinguish between the main app and its children.
> > >
> > > Another thread said abnormal disconnects could leave MON$ATTACHMENTS thinking a connection is still active for two or more hours. When a client reboots from a Windows freeze, they will recover quicker than that, and will expect to resume work. Obviously, we need a way to force MON$ATTACHMENTS to refresh. Is it possible for a Connect or Disconnect trigger to force such a refresh? If so, how? Or, is there a way to reliably make the app reconnect to an abnormally disconnected connection?
> > >
> >
>