On Dec 19, 2008, at 10:34 AM, Jeff Schmitz wrote:
Yes, Chuck pointed that out to me too (whoops). I just didn't
think to question how a database company would spell it =8^O.
You need to select the Danish dictionary to spell check that.
Chuck
On Dec 19, 2008, at 12:11 PM, Kieran Kelleh
Yes, Chuck pointed that out to me too (whoops). I just didn't think
to question how a database company would spell it =8^O.
On Dec 19, 2008, at 12:11 PM, Kieran Kelleher wrote:
indexes or indices: From elitist Dictionary.app ;-)
index |ˈɪnˈdɛks|noun ( pl. -dexes |ˈɪnˈdɛksəz| or esp. in
indexes or indices: From elitist Dictionary.app ;-)
index |ˈɪnˈdɛks|noun ( pl. -dexes |ˈɪnˈdɛksəz| or esp. in
technical use -dices |ˈɪndəˈsiz|)
On Dec 19, 2008, at 9:05 AM, Jeff Schmitz wrote:
btw, why does the Mail app say 'indeces' is misspelled? Guess we're
supposed to stick to the m
On Dec 19, 2008, at 6:26 AM, Jeff Schmitz wrote:
Whoops, I think I misread the suggestion.
No, there wasn't an index for WinAnalysis.comboTeamID. And creating
one makes a HUGE HUGE HUGE (enough emphasis??) difference. from
minutes to less than a second to load the page. So it was the
On Dec 19, 2008, at 5:55 AM, Jeff Schmitz wrote:
A to-many relationship is what I was thinking. Maybe Team -->>
WinAnalysis. You might need to add an attribute to maintain
ordering on the destination entity (e.g. which win?) as to-many
relationships are unordered by definition (in EOF, n
Whoops, I think I misread the suggestion.
No, there wasn't an index for WinAnalysis.comboTeamID. And creating
one makes a HUGE HUGE HUGE (enough emphasis??) difference. from
minutes to less than a second to load the page. So it was the
'indexes' after all.
Again, many thanks, I should
OK, I tried to do this, and in the process hit a dialogue that said I
had to change my transaction settings to be serializable, pessimistic,
read write. Are these setting just for the FrontBase Manager app, or
global (i.e. also for my webobjects app?).
Anyway, after saying ok, change my tr
On Dec 18, 2008, at 10:19 PM, Guido Neitzer wrote:
On 18.12.2008, at 21:26, Chuck Hill wrote:
FB might have fixed that. I am pretty sure that someone was
complaining about the OR vs IN difference being quite significant.
That might have been FB 3. You know us old folks, we all live in
On 18.12.2008, at 21:26, Chuck Hill wrote:
FB might have fixed that. I am pretty sure that someone was
complaining about the OR vs IN difference being quite significant.
That might have been FB 3. You know us old folks, we all live in
the past. ;-)
I'm not sure on OR vs. IN, but Front
On Dec 18, 2008, at 8:40 PM, Jeff Schmitz wrote:
Does WinAnalysis.comboTeamID have an index? I'd guess that it does
and that the index is corrupt. Or that is one VERY large table and
there is no index. If you can get FrontBase to use an IN instead
of ORs that will also make it faster, b
On Dec 18, 2008, at 8:36 PM, Jeff Schmitz wrote:
I can agree that it's more a "collection" than a "relation", but
what I don't understand is, how is a "collection" implemented
differently than a "relationship" in EOModeler? Somewhere along the
line I got the idea that using the "MutableA
Just one varchar50 and a handful of ints.
On Dec 18, 2008, at 10:39 PM, Clark Mueller wrote:
LOB refers to large object (i.e. a blob or clob type). Are any of
those columns in WinAnalysis a blob or a clob? II am guessing not,
from the column names I see there... but if you are, and you're
Does WinAnalysis.comboTeamID have an index? I'd guess that it does
and that the index is corrupt. Or that is one VERY large table and
there is no index. If you can get FrontBase to use an IN instead of
ORs that will also make it faster, but you have some kind of hunka
burning serious SQL
LOB refers to large object (i.e. a blob or clob type). Are any of
those columns in WinAnalysis a blob or a clob? II am guessing not,
from the column names I see there... but if you are, and you're
fetching 189 blobs, I would think that could possibly be a contributor.
Clark
On 18-Dec-08, a
I can agree that it's more a "collection" than a "relation", but
what I don't understand is, how is a "collection" implemented
differently than a "relationship" in EOModeler? Somewhere along the
line I got the idea that using the "MutableArray" prototype was bad
juju, so if not that, and
On Dec 18, 2008, at 7:41 PM, Jeff Schmitz wrote:
By consider a different design, do you mean something like the below
(from the wiki)? Coming form an OO world, I perhaps took the
paradigm too far and chopped up my data into too many tables?
I'd consider going a step back before that and r
On Dec 18, 2008, at 8:22 PM, Mike Schrag wrote:
Does WinAnalysis.comboTeamID have an index? I'd guess that it does
and that the index is corrupt. Or that is one VERY large table and
there is no index. If you can get FrontBase to use an IN instead
of ORs that will also make it faster, bu
Does WinAnalysis.comboTeamID have an index? I'd guess that it does
and that the index is corrupt. Or that is one VERY large table and
there is no index. If you can get FrontBase to use an IN instead of
ORs that will also make it faster, but you have some kind of hunka
burning serious SQL
On Dec 18, 2008, at 8:11 PM, Jeff Schmitz wrote:
"LOBs"? Sorry, I'm not familiar with that term.
I have set the EOAdaptorDebugEnabled flag. Below is the output from
a ERXBatchFetchUtilities.batchFetch call that takes 94 seconds.
It's traversing something like a 1 to 65 to 2 relationship
"LOBs"? Sorry, I'm not familiar with that term.
I have set the EOAdaptorDebugEnabled flag. Below is the output from a
ERXBatchFetchUtilities.batchFetch call that takes 94 seconds. It's
traversing something like a 1 to 65 to 2 relationship.
Dec 18 20:48:38 netBrackets[2001] (ERXNSLogLog4
Jeff,
What does your model/database schema actually look like? Have you
tried setting EOAdaptorDebugEnabled to true in your launch config (or
via property)? How do the LOBs fit into your design?
Clark
On 18-Dec-08, at 7:41 PM, Jeff Schmitz wrote:
By consider a different design, do you
By consider a different design, do you mean something like the below
(from the wiki)? Coming form an OO world, I perhaps took the paradigm
too far and chopped up my data into too many tables? e.g. Would
denormalizing my 1 --> 65 --> 2 tables into a single table help? Or
would a better
On Dec 17, 2008, at 9:25 AM, Jeff Schmitz wrote:
Yes, now that I think of it, there is one of these "crazy" joins
that's probably coming into play that joins each of my 7000 rows
with 65 rows in a different table, so that table must have about
450,000 rows. Any good optimization approache
Yes, now that I think of it, there is one of these "crazy" joins that's
probably coming into play that joins each of my 7000 rows with 65 rows in a
different table, so that table must have about 450,000 rows. Any good
optimization approaches for these type of one to "very many" relationships?
Either some crazy joins with other tables or something you are not
aware of is going on. 7K rows is tiny.
definitely ... this demands sql debug to be turned on ... my money is
on your console streaming sql faster than you can read.
ms
___
Do not p
Either some crazy joins with other tables or something you are not
aware of is going on. 7K rows is tiny.
Chuck
On Dec 16, 2008, at 9:07 PM, Jeff Schmitz wrote:
hmm, I'm not doing an insert at all, just a read. Kind of thought
there must be something else too though (with my limited exp
hmm, I'm not doing an insert at all, just a read. Kind of thought
there must be something else too though (with my limited experience)
but figured indexing would be a good thing to do regardless before
digging into debugging the real culprit here.
Jeff
On Dec 16, 2008, at 11:01 PM, Mike S
More than a minute to insert to a 7000 row table?
Do other operations on the same DB take an appropriate amount of
time? If not I would start looking at DNS or other connectivity
issues. I can't fathom a FB DB sucking at that level.
this was my first thought, too ... something else is going
More than a minute to insert to a 7000 row table?
Do other operations on the same DB take an appropriate amount of time?
If not I would start looking at DNS or other connectivity issues. I
can't fathom a FB DB sucking at that level.
Jeff Schmitz wrote:
Am reading the frontbase docs now. N
Am reading the frontbase docs now. No problem on the CPU load, server
is offline just being readied for production using my snazzy new
EOFized app (which currently takes a minute+ per page request =8*O)
Last question, I'm thinking PERSERVE TIME over PERSERVE SPACE. Disk
space is CHEAP. r
On 16.12.2008, at 21:10, Jeff Schmitz wrote:
SQL?!? So unclean ;-)
Is adding the index using frontbase manager something that can be
done after a table is populated? Or will I need to export and re-
import my data? Sorry, I'm far from a database expert.
You can add indexes at any time.
Is adding the index using frontbase manager something that can be
done after a table is populated? Or will I need to export and re-
import my data? Sorry, I'm far from a database expert.
...
Yes, you can add them after the fact. The only time you can't do
that is if it is an unique index a
On Dec 16, 2008, at 8:10 PM, Jeff Schmitz wrote:
SQL?!? So unclean ;-)
Use lots of soap and hot water afterwards.
Is adding the index using frontbase manager something that can be
done after a table is populated? Or will I need to export and re-
import my data? Sorry, I'm far from a d
SQL?!? So unclean ;-)
Is adding the index using frontbase manager something that can be done
after a table is populated? Or will I need to export and re-import my
data? Sorry, I'm far from a database expert.
On Dec 16, 2008, at 9:13 PM, Chuck Hill wrote:
On Dec 16, 2008, at 6:23 PM,
On Dec 16, 2008, at 6:23 PM, Guido Neitzer wrote:
On 16.12.2008, at 17:56, Jeff Schmitz wrote:
Hello,
I've populated my eo tables with data and my queries are VERY
slow. A table with about 7000 entries takes a couple minutes to
retrieve a single EO (i.e. row of data). I guessing I need
On 16.12.2008, at 17:56, Jeff Schmitz wrote:
Hello,
I've populated my eo tables with data and my queries are VERY
slow. A table with about 7000 entries takes a couple minutes to
retrieve a single EO (i.e. row of data). I guessing I need to tell
the database (frontbase) that it needs to
Hello,
I've populated my eo tables with data and my queries are VERY
slow. A table with about 7000 entries takes a couple minutes to
retrieve a single EO (i.e. row of data). I guessing I need to tell
the database (frontbase) that it needs to index on the attributes
(columns) that I co
37 matches
Mail list logo
