I do believe you in that it's *theoretically* easier to do all these
things with fb2 but there are 2 reasons I'm wary about fb2:

1) I have given fb2 a try already and the first thing that ocurred was
a problem with events not being posted correctly, so I signed up to
firebird-devel and posted my problem and it came out to be a bug in
the server..it's probably fixed by now, but it made me wary...

2) I think there's a big difference between writing applications USING
fb and being really into this whole developing community thing..maybe
fb2 intl architecture is easier, again, *theoretically*, but with
fb1.5 I have david schnepper's tutorial on how to write my own
collation which i simply have to follow and it works..with fb2 - it
seems - all i have is the source code and no idea about how to change
which files and how to compile them if i want to write my own
collation..if you're not so much of an experienced programmer you look
at the source code and say "Ooookayy"

I'm writing this application for my end-of-studies project (as I've
said earlier in this forum) and I've been working on it for the whole
year already and I really do need and want to finish by the end of the
year and there are so many little things that need to be done that I
really don't think I can risk trying fb2 at this point in time..I've
done too much going back and forth already, I can't afford to waste
any more time..

Now, coming back to my problem:

In a normal situation, the user of my application would repeatedly
send the same sql request to the server, only with changed parameters;
the request could be something like the following:


select * from dicentries d
inner join get_next_20_dicentries_by_asterm('a', 25) g
on d.id = g.id


get_next_20_dicentries_by_asterm('a', 25) would simply return the
field ID from table DICENTRIES for the first 20 records "where asterm

>= 'a' and ID >= 25" and "order(ed) by asterm ascending, id ascending)"

suppose the last one of these 20 records has ASTERM = 'ZOO', ID = 130,
and the user is scrolling forward, not backward, then the next query
would simply be:


select * from dicentries d
inner join get_next_20_dicentries_by_asterm('ZOO', 130) g
on d.id = g.id


and so on and so forth...

now, every time i request 20 new records, the whole table DICENTRIES
is sorted "by asterm ascending, id ascending" before returning just
the first 20 of this big and sorted result set..is there no way to
realize for the server that a received query is the exact same query
as the one before but with changed parameters so that the result set
from the query before could be reused??

thanx,

martin

--- In firebird-support@yahoogroups.com, Alexandre Benson Smith
<iblist@...> wrote:

>
> martinknappe wrote:
> > Hi,
> > now I have an idea; a bit complicated to explain, but does any one
> > know how I could achieve the following FROM WITHIN A TRIGGER:
> >
> > -get the collation key of a varchar object
> > -convert the key into a one-byte-per-char string (i.e. each character
> > is "calculated" by using the byte as and index into ascii)
> > -append a 4-byte (big) integer object likewise to this string
> >
> > the thing is, i am really using NOT unicode_fss collation, but my own
> > unicode collation which i wrote according to David Schnepper's paper
> > (see here:
> > http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_collation); i
> > included unicode_fss in the script so no one gets confused by my
> > collation's name...
> > Now, my collation GUARANTESS that the collation key of a unicode_fss
> > object is exactly as long (in bytes) as there are number of characters
> > (NOT BYTES) in the unicode_fss string. So an 80-character string would
> > have a collation key of 80 bytes, no more...
> > And my idea is to introduce a new field in table dicentries which
> > would be calculated from column asterm and id each time an entry in
> > dicentries is inserted or modified
> > Assuming this new field was called "ASTERMCOLLATE", instead of writing
> > "order by asterm, id", I could simply write "order by
> > ASTERMCOLLATE"..and because this column could be sorted by codepoint,
> > it would even be possible to easily create an index on it
> >
> > I hope some of you can help me,
> > thanx,
> >
> > Martin
> >
> >
> >
> Martin,
>
> I think you should try FB 2 because it has a new INTL Interface, that
> handles correctly Unicode chars. I think you will spend energy

unecessary.

>
> Even if you need your own collation, it will be far more simple with

the

> new INTL Interface design.
>
> And with FB 2 the 252 bytes index size are gone.
>
> see you !
>
> --
> Alexandre Benson Smith
> Development
> THOR Software e Comercial Ltda
> Santo Andre - Sao Paulo - Brazil
> www.thorsoftware.com.br
>