Well, I have this minor problem solved.

It had to do with knowing if we can do a full table dump to Excel and this
works fine for me:



SELECT DISTINCT

1 / I.RDB$STATISTICS

FROM

RDB$INDEX_SEGMENTS RIS

INNER JOIN RDB$INDICES I ON

(RIS.RDB$INDEX_NAME = I.RDB$INDEX_NAME)

WHERE

I.RDB$RELATION_NAME = 'ADDRESS ' AND

I.RDB$UNIQUE_FLAG = 1



The only variable here is the table name and the result is very accurate.



RBS





_____

From: firebird-support@yahoogroups.com
[mailto:firebird-support@yahoogroups.com] On Behalf Of Timothy Madden
Sent: 01 October 2008 15:38
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] What programming languages and toolkits do
you use to access Firebird?



On Wed, Oct 1, 2008 at 5:26 PM, Martijn Tonies <m.tonies@upscene.
<mailto:m.tonies%40upscene.com> com> wrote:

>
>> >> This SELECT Count(*) problem is really incredible. I can understand
>> >> concurent
>> >> transactions see different versions of the same table. Why is it
>> >> difficult for every
>> >> of these versions to also have their own row count ?
>> >
>> > Because such count would have to be kept in system tables, and it would
>> > mean versioning system tables - which has proven to be tricky so far.
>>
>>
>> How about letting the system tables reflect the base version of the table
> and
>> put the per-transaction row-count toghether with the version-specific

data

> of
>> the table ?
>
> No offence, but this only makes sense if you do a "select count(*) from
> table".
>
> That is: no specific columns (cause then the result can be different), no
> WHERE
> clause.
>
> Why go through all this trouble for something that is, per transaction,
> hardly in use?

Well, the OP seems to want his tables displayed in some grid control,
which needs a scroll bar, and someone else reported an 8 milion rows
table needs about 12s to get the row count.

I believe many applications can be made to work without reading the row
count in advance, and I would do this every time I can, but if I need the
row count for a base table I would still expect to have it in a reasonable
amount of time.

Thank you,
Timothy Madden





[Non-text portions of this message have been removed]