Re: [firebird-support] Re: server 2.5.8 deadlocked

2018-02-12 Thread Hamish Moffatt ham...@risingsoftware.com [firebird-support] 
On 13/02/18 17:55, Dmitry Yemanov dim...@users.sourceforge.net 
[firebird-support] wrote:
> 13.02.2018 05:07, Hamish Moffatt wrote:
>
>> I attached gdb and dumped the state of all threads, which shows every
>> one of them is waiting on a mutex or futex, ie it's dead locked. I've
>> attached the trace.
> You need to download the debug symbols (Firebird-debuginfo-* package)
> and copy them into your FB installation directory. Then take the
> backtrace again.

OK I will get those next time.

Hamish






++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[firebird-support] Re: server 2.5.8 deadlocked

2018-02-12 Thread Dmitry Yemanov dim...@users.sourceforge.net [firebird-support] 
13.02.2018 05:07, Hamish Moffatt wrote:

> I attached gdb and dumped the state of all threads, which shows every
> one of them is waiting on a mutex or futex, ie it's dead locked. I've
> attached the trace.

You need to download the debug symbols (Firebird-debuginfo-* package) 
and copy them into your FB installation directory. Then take the 
backtrace again.


Dmitry







++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

Re: [firebird-support] server 2.5.8 deadlocked

2018-02-12 Thread Hamish Moffatt ham...@risingsoftware.com [firebird-support] 
On 13/02/18 13:07, Hamish Moffatt ham...@risingsoftware.com 
[firebird-support] wrote:


I'm getting the Firebird 2.5 superclassic server on Linux deadlocking
regularly at the moment. Twice in one day last week, and again today
after uptime of less than 6 hours.

I just upgraded to 2.5.8 today, from 2.5.6. Our workload isn't huge, but
we do have a lot of small databases and maybe up to 100 client
connections at once.



For what it's worth, I have occasional remote connections over the 
Internet with latency of about 160ms (US east coast to Australia).


This is very slow with Firebird 2.5 but we only need to fetch one row 
from a db so it's acceptable to us.


Twice I think the deadlock condition has coincided such with a remote 
request.


Could this be a factor?

Hamish

Re: [firebird-support] server 2.5.8 deadlocked

2018-02-12 Thread HuI HaO huihaoc...@hotmail.com [firebird-support] 
any solution find？i have same problem also

From Hugo Chia

On 13 Feb 2018, at 10:07 AM, Hamish Moffatt 
ham...@risingsoftware.com [firebird-support] 
mailto:firebird-support@yahoogroups.com>> 
wrote:



I'm getting the Firebird 2.5 superclassic server on Linux deadlocking
regularly at the moment. Twice in one day last week, and again today
after uptime of less than 6 hours.

I just upgraded to 2.5.8 today, from 2.5.6. Our workload isn't huge, but
we do have a lot of small databases and maybe up to 100 client
connections at once.

I attached gdb and dumped the state of all threads, which shows every
one of them is waiting on a mutex or futex, ie it's dead locked. I've
attached the trace.

How can I debug this?

Would I be better off with superserver?

I can't connect with isql when it's in this state (it hangs).

Hamish

--

Thread 54 (Thread 0x9342bb40 (LWP 31639)):
#0 0xb7fccd81 in __kernel_vsyscall ()
#1 0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2 0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3 0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4 0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5 0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6 0xb782a27a in start_thread (arg=0x9342bb40) at pthread_create.c:333
#7 0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 53 (Thread 0x8f7adb40 (LWP 31616)):
#0 0xb7fccd81 in __kernel_vsyscall ()
#1 0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2 0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3 0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4 0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5 0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6 0xb782a27a in start_thread (arg=0x8f7adb40) at pthread_create.c:333
#7 0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 52 (Thread 0x8ffaeb40 (LWP 31603)):
#0 0xb7fccd81 in __kernel_vsyscall ()
#1 0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2 0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3 0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4 0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5 0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6 0xb782a27a in start_thread (arg=0x8ffaeb40) at pthread_create.c:333
#7 0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 51 (Thread 0x94c2eb40 (LWP 30369)):
#0 0xb7fccd81 in __kernel_vsyscall ()
#1 0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2 0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3 0xb7b94bc8 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4 0xb7b95e3d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5 0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6 0xb782a27a in start_thread (arg=0x94c2eb40) at pthread_create.c:333
#7 0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 50 (Thread 0x9a439b40 (LWP 30333)):
#0 0xb7fccd81 in __kernel_vsyscall ()
#1 0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2 0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3 0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4 0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5 0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6 0xb782a27a in start_thread (arg=0x9a439b40) at pthread_create.c:333
#7 0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 49 (Thread 0x9542fb40 (LWP 28376)):
#0 0xb7fccd81 in __kernel_vsyscall ()
#1 0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2 0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3 0xb7b94bc8 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4 0xb7b95e3d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5 0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6 0xb782a27a in start_thread (arg=0x9542fb40) at pthread_create.c:333
#7 0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 48 (Thread 0x917b1b40 (LWP 28374)):
#0 0xb7fccd81 in __kernel_vsyscall ()
#1 0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2 0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3 0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4 0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5 0xb7a64835 in

[firebird-support] server 2.5.8 deadlocked

2018-02-12 Thread Hamish Moffatt ham...@risingsoftware.com [firebird-support] 
I'm getting the Firebird 2.5 superclassic server on Linux deadlocking 
regularly at the moment. Twice in one day last week, and again today 
after uptime of less than 6 hours.

I just upgraded to 2.5.8 today, from 2.5.6. Our workload isn't huge, but 
we do have a lot of small databases and maybe up to 100 client 
connections at once.


I attached gdb and dumped the state of all threads, which shows every 
one of them is waiting on a mutex or futex, ie it's dead locked. I've 
attached the trace.

How can I debug this?

Would I be better off with superserver?


I can't connect with isql when it's in this state (it hangs).


Hamish


  --

Thread 54 (Thread 0x9342bb40 (LWP 31639)):
#0  0xb7fccd81 in __kernel_vsyscall ()
#1  0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3  0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4  0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5  0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6  0xb782a27a in start_thread (arg=0x9342bb40) at pthread_create.c:333
#7  0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 53 (Thread 0x8f7adb40 (LWP 31616)):
#0  0xb7fccd81 in __kernel_vsyscall ()
#1  0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3  0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4  0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5  0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6  0xb782a27a in start_thread (arg=0x8f7adb40) at pthread_create.c:333
#7  0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 52 (Thread 0x8ffaeb40 (LWP 31603)):
#0  0xb7fccd81 in __kernel_vsyscall ()
#1  0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3  0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4  0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5  0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6  0xb782a27a in start_thread (arg=0x8ffaeb40) at pthread_create.c:333
#7  0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 51 (Thread 0x94c2eb40 (LWP 30369)):
#0  0xb7fccd81 in __kernel_vsyscall ()
#1  0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3  0xb7b94bc8 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4  0xb7b95e3d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5  0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6  0xb782a27a in start_thread (arg=0x94c2eb40) at pthread_create.c:333
#7  0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 50 (Thread 0x9a439b40 (LWP 30333)):
#0  0xb7fccd81 in __kernel_vsyscall ()
#1  0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3  0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4  0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5  0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6  0xb782a27a in start_thread (arg=0x9a439b40) at pthread_create.c:333
#7  0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 49 (Thread 0x9542fb40 (LWP 28376)):
#0  0xb7fccd81 in __kernel_vsyscall ()
#1  0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3  0xb7b94bc8 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4  0xb7b95e3d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5  0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6  0xb782a27a in start_thread (arg=0x9542fb40) at pthread_create.c:333
#7  0xb7753b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 48 (Thread 0x917b1b40 (LWP 28374)):
#0  0xb7fccd81 in __kernel_vsyscall ()
#1  0xb782fb9b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xb7beab97 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#3  0xb7d98653 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#4  0xb7d9dc9d in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#5  0xb7a64835 in ?? () from /usr/lib/i386-linux-gnu/libfbembed.so.2.5
#6  0xb782a27a in start_thread (arg=0x917b1b40) at pthread_create.c:333
#7  0xb7753b56 in clone () at ../sysdeps/unix/

[firebird-support] Linux Journal

2018-02-12 Thread Gary Benner g...@benner.co.nz [firebird-support] 

Hello Helen,

It's been a while, but I still read your posts on the FB (not 
facebook!!) forums!


I saw this article below and thought I might try and lend a hand to 
Firebird by taking up the offer, but then realised there was a better 
person to do so  so passing the baton if you wish to take it up!


http://www.linuxjournal.com/content/write-linux-journal

I've subscribed to LJ for many years, and was sad when last year they 
decided to stop publishing, but they have been resurrected thank goodness.


I trust all is well with you. If you are ever down in the BOP, please 
come and see us. We live on top of the Kaimais (literally) so an easy 
stop off point!.


Kind regards

Gary

PS: Do you ever hear from Jim and Ann these days? What are they up to? 
Sailing?

Re: [firebird-support] Adding a field with NOT NULL constraint

2018-02-12 Thread Aldo Caruso aldo.car...@argencasas.com [firebird-support] 

Hello Helen,

    One of the most dangerous consequences of forgetting to update 
values of the new added field, when it has constraints, is that, when 
recovering a database from a backup, errors are risen and the recover 
process aborts. Although backups are done raising no error, that doesn't 
guarantees that data is consistent. Only when a restore is done, data 
integrity is fully checked. Normally, backups are done far more 
frequently that restore, as they are done at least on a daily basis.


    To prevent or at least mitigate this risk, a cron job could be 
created in order to daily recover the database from its last daily 
backup onto another file.


    gbak -replace_database -se localhost:service_mgr -user sysdba 
-password   



    If an inconsistence were found, an error would be thrown and the 
cron job user will receive an e-mail.


    Is there a better way to test full integrity of all the data than a 
restore ?


Thanks

Aldo Caruso


El 10/02/18 a las 15:41, Helen Borrie hele...@iinet.net.au 
[firebird-support] escribió:


Hello Aldo,

> My questions are the following:

> 1) Is the intended effect to fill behind the scenes a newly created
> field with its default value when there is a not null constraint ?

No. Only inserts subsequent to the commit of the DDL for the new
field will use the default in the case where no value is provided.

Note, also, that default values apply only to inserts and only where
the field is absent from the field list for the insert.

> 2) Could this behind the scenes filling fail because of an update or
> insert of another concurrent transaction ?

There is no "behind the scenes filling". If you add a NOT NULL field
to an existing table, or change a nullable field to NOT NULL, then you
are responsible for filling the field yourself, immediately after the
DDL is committed.

update mytable set newfield = 1 where newfield is null

update mytable set existingfield = 1 where existingfield is null

As for the effect on concurrent transactions, you should not be
attempting to change the structure of a table while it is in use.

HB

> 
> Posted by: Aldo Caruso 
> 

> ++

> Visit http://www.firebirdsql.org and click the Documentation item
> on the main (top) menu. Try FAQ and other links from the left-side 
menu there.


> Also search the knowledgebases at
> http://www.ibphoenix.com/resources/documents/

> ++
> 

> Yahoo Groups Links

--
Kind regards,
Helen Borrie

Re: [firebird-support] Re: Adding a field with NOT NULL constraint

2018-02-12 Thread Aldo Caruso aldo.car...@argencasas.com [firebird-support] 

Dmitry,

    Thanks for your answer.

    Also note that when a not null field is created with a default 
value ( test4 ), not only any select returns its default value but also 
the engine considers it in compare statements as if it contained the 
default value.


    This is also true if you decide to change the default value 
afterwards: compare statements will vary accordingly.


    Example

alter table table1 add test4 integer default 4 not null;

select distinct test4, iif(test4 = 4,1,0) as t4 from table1;

Result:
 test4  t4
4     1

If you change the default value afterwards:

alter table t1 alter column test4 set default 5;

select distinct test4, iif(test4 = 5,1,0) as t4 from table1;

Result:
 test4  t4
5     1

In other words, this has the same effect as if the field value changed 
when you changed its default value.


Extending Helen advice, whenever you add or change constraints related 
to the definition of a field using a DDL statement, you must update the 
value of that field in all records by means of a DML statement in order 
to ensure that no inconsistent data is saved or shown, whichever client 
library you use.


Thanks,
Aldo Caruso

El 11/02/18 a las 02:40, Dmitry Yemanov dim...@users.sourceforge.net 
[firebird-support] escribió:


10.02.2018 22:33, Aldo Caruso wrote:
>
> A strange behavior is seen in the combination not null and no default
> value. It is returned as a 0 for selects but treated as a NULL when
> comparing.

In fact, the engine returns NULL. But query prepare describes the output
descriptor as NOT NULL. Some connectivity layers (including ISQL, IIRC)
get fooled, as NULL is not expected from a NOT NULL descriptor, and zero
/ empty string is returned. I recall that IBExpert is able to return
NULL in this case.

Dmitry

Re: [firebird-support] Adding a field with NOT NULL constraint

2018-02-12 Thread Aldo Caruso aldo.car...@argencasas.com [firebird-support] 
Helen,

     Thank you very much for you advices.

     As a matter of fact, I had been changing table structures and 
stored procedures while other clients were connected since many years 
with no problems. Nevertheless, what you say is indeed true and can give 
rise potentially to trouble.

     Better to disconnect clients ( during for a low activity hours ) 
before applying DDL statements.

     Thanks.

Aldo Caruso


El 10/02/18 a las 17:32, Helen Borrie hele...@iinet.net.au 
[firebird-support] escribió:
>>    Your last advice concerns me a bit. Is it also valid for
>> changing stored procedures or triggers ?
> As an abiding principle - yes.  But, for SPs and triggers, the effect
> varies according to a few factors.  The BLR for these modules is
> cached on first use.  Changes conducted whilst the module is in cache
> will not take effect until the cached copy is removed.
>
> For Classic and Superclassic, each user has a private cache that
> disappears when that user detaches from the database.  For
> Superserver, the cache is shared, so the changes will not take effect
> for any user until all users detach.
>>    Should I have always to disconnect every client before   executing 
>> DDL sentences ?
> My advice is "Yes, always".  There might be some conditions where
> changing things while users are online is plain sailing but how would
> you know for certain?  Whilst the engine may allow you to effect
> changes without throwing errors or corrupting on-disk structures, it
> would be difficult to assure yourself that you are not going to
> corrupt the in-memory structures that users already have in place.
>
> And, when all is said and done, assumptions about the structure of
> the database objects are made in the client application and any active
> request refers to the status quo when that client connected.
>
> HB
>
>
>
>
> 
>
> 
>
> ++
>
> Visit http://www.firebirdsql.org and click the Documentation item
> on the main (top) menu.  Try FAQ and other links from the left-side menu 
> there.
>
> Also search the knowledgebases at 
> http://www.ibphoenix.com/resources/documents/
>
> ++
> 
>
> Yahoo Groups Links
>
>
>







++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu.  Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/ 

++


Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-dig...@yahoogroups.com 
firebird-support-fullfeatu...@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-unsubscr...@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/