Hi there, for years and years, we happily use FrontBase. Lately though we are bumping into somewhat weird behaviour: we observe inexplicably long fetches, even with tables which are not extremely big, no joins, trivial conditions. What's even more intriguing is that in sql92, it was much faster. Even so, the problem was at the FB (not application) side, for an index did help tremendously. Does not make really sense to me, and I wonder whether there might be some weird problem in the FB itself, which might raise its head soon and bite us hard.
- the table contains about 16 000 rows, that's not too many; - the fetch condition is trivial, just WHERE SOME_BOOLEAN_COLUMN = false; - the number of found rows is only 13 currently (and never exceeded 100). These fetches took seconds — usually about 1200 ms, not once below 1000, occasionally almost 3000 ms. When I've tried the very same fetch in sql92, it was instantaneous, which feels pretty weird too and lead me to a suspicion that the problem is at the application side. Nevertheless it was not: I just have added an index for the column, and the fetches are ways quicker now (usually below 30 ms). What intrigues me and the reason I write this mail, it does not seem to me reasonable that a plain fetch from a table of ~16K rows which yields (considerably) less than 100 result rows, without any join and with a completely trivial condition, could (without an index) take that long. Does it make any sense to you, who understand SQL/FB better than me? Is that normal? There are other fetches from the same table, with considerably more complex conditions, taking at worst a couple tenths of second; that seems normal to me. Thanks and all the best, OC
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
