Thanks for the suggestion. That may helps.

William

On Fri, Apr 1, 2011 at 12:19 PM, JackR <jack@...> wrote:

>
>
>
>
> Where I used to work, they had a similar limitation on MS SQL Server, only
> the number was more like 150. So they built a function in their VB app that
> took a string of more than 150 values in the form of ID IN(1,2,3,4...,etc.)
> and returned multiple strings in the form of
> ID IN(1,2,3,4...)
> OR ID IN (151,152,153...)
> etc.
> Would this approach work for you?
> If you are using Delphi, it seems like a StringList would make the job a
> lot easier.
>
>
> --- In firebird-support@yahoogroups.com, Wei Yu <william.wei.yu@...>
> wrote:
> >
> > HI, Kjell
> >
> > We have facing the same situation like yours, We don't have a good
> > soluation other than putting them in a IN clause. By putting those into a
> > temp table, will hits the performance. If you have a good approach,
> please
> > let me know.
> >
> > Regards,
> >
> > William
> >
> >
> > On Fri, Apr 1, 2011 at 3:27 AM, Kjell Rilbe <kjell.rilbe@...> wrote:
> >
> > > Den 2011-04-01 07:40 skrev karolbieniaszewski s�h�r:
> > > > Having 1500 values in "in" is not good choice
> > > > but try change this to
> > > >
> > > > in (
> > > > SELECT 601089 FROM RDB$DATABASE
> > > > UNION
> > > > SELECT 601092 FROM RDB$DATABASE
> > > > ...
> > > > )
> > > >
> > > > but better will be to fill some temporary table with this data
> > >
> > > Yes, I'm aware that this isn't optimal. It's the way ECO fetches data
> > > for a list of object identities (i.e. primary keys). With ECO, if you
> > > navigate from a list of objects to related objects, e.g. from a list of
> > > "Car" objects to their "Tires", ECO will, if you so require, load data
> > > for all the cars' Tyre objects. It will do this by issuing a select,
> > > listing the PK:s for the Tyre objects in an IN clause.
> > >
> > > It is possible that it would be better with a temp table, but 1) it's
> > > not the way it currently works, and 2) would it really perform better?
> > > Inserting 50000 PK:s in a temp table just to join it with a normal
> > > table, and then deleting the temp table seems like more work than to
> > > issue 50000/1500 = 34 selects with 1500 keys each in an in (...)
> clause.
> > > But maybe I'm wrong...
> > >
> > > Anyway, the issue is not if this is the optimal way to do things, the
> > > issue is that FB has a bug, albeit rather unimportant. It says to
> > > support 1500 values but supports no more than 1499.
> > >
> > > Kjell
> > > --
> > > --------------------------------------
> > > Kjell Rilbe
> > > DataDIA AB
> > > E-post: kjell@...
>
> > > Telefon: 08-761 06 55
> > > Mobil: 0733-44 24 64
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > Visit http://www.firebirdsql.org and click the Resources item
> > > on the main (top) menu. Try Knowledgebase and FAQ links !
> > >
> > > Also search the knowledgebases at http://www.ibphoenix.com
> > >
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
> > [Non-text portions of this message have been removed]
> >
>
>
>


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