Den 2012-06-03 21:23 skrev Alec Swan såhär:
> On Sun, Jun 3, 2012 at 1:06 PM, Leyne, Seanwrote:
>> Yes, there is a limit to the length of an Firebird index name, but you
>> could come up with an algorithm which would be able to shorten the names as
>> appropriate. For example an compound index of
>
Sean,
I would like to note that the fact that LEFT JOIN can generate an optimal
plan where INNER JOIN fails indicates that all our index statistics are
up-to-date and that there is some discrepancy between LEFT and INNER JOIN
optimization that has already bit us several times. The good thing about
On Sun, Jun 3, 2012 at 2:55 PM, dancooperstock wrote:
> OK, I gave up and wrote my own UDF. It ended up having exactly the same
> problem as the one in FreeUDFLib, namely that if the first character, which
> gets copied directly into the result string, is accented, you get
> "Malformed String" wh
Alec,
> Sean,
>
> The query you proposed will not produce the same result because you are
> sorting and topping the join before applying the filter.
You are correct.
But a small change to my proposed query would resolve that issue, the
new/corrected query would be:
SELECT
FIRST (1000)
PHY
Sean,
The query you proposed will not produce the same result because you
are sorting and topping the join before applying the filter. The
original query was joining and filtering first and after that sorting
and topping. So, your query will always return a subset of rows of the
original query.
T
Thank you!
I consider this issue resolved with one side note that having PLAN hint
which affects ORDER BY execution before ORDER BY clause is misleading.
Alec
On Sun, Jun 3, 2012 at 1:15 PM, Michael Ludwig wrote:
> **
>
>
> Alec Swan schrieb am 03.06.2012 um 09:01 (-0600):
>
> >
> > Is there o
Sean, you nailed the reason on the head - the FB restriction on index
names. In fact, on SQL Server we have pretty index names :) Unfortunately,
we didn't have the resources to spend in prettyfying the index names at the
time. At this point it's even harder to do this because of upgrade
scenarios.
Dmitry,
Thanks for clearing up when fb_sort files are being deleted.
We are certainly looking for ways to "Just fix your application", however
with complex logic-intensive applications it's not always that simple.
"change %TEMP%" is just not going to work in any enterprise environment.
You can s
Alec Swan schrieb am 03.06.2012 um 09:01 (-0600):
>
> Is there online docs for SELECT syntax?
There's an online HTML version of the SQL reference linked to from the
overview page:
http://www.ibphoenix.com/files/60sqlref.html
> On Sun, Jun 3, 2012 at 8:59 AM, Alec Swan wrote:
> >
> > I found FB
> We create indexes programmatically and we we generate their names based
> on their definition, such the columns they index.
If that is the case, why is the name gibberish?
You could create an index which has the name(s) of the source fields (ie.
"PK_PhysicalCopy.ID" or "FK_PhysicalCopy.CopyI
OK, I gave up and wrote my own UDF. It ended up having exactly the same problem
as the one in FreeUDFLib, namely that if the first character, which gets copied
directly into the result string, is accented, you get "Malformed String" when
it is returned.
This is despite the fact that in my first
Alex,
> We tracked down the query that generated a 10GB temp file running against
> a 1.5GB database. Can anybody explain why the query is not using an index
> on PHYSICAL_COPY."COMMIT_NUMBER"?
Cause the optimizer decided that the "cost" of navigating that index was more
than filtering the resul
Hello, Alec!
Sunday, June 3, 2012, 10:17:05 PM, you wrote:
AS> Actually, FB correctly deletes fb_sort file used by a transaction after the
AS> transaction completes.
wrong. sort files being deleted when query that have plan sort fetched
to EOF, i.e. to the last record. Same happens, for example,
Vlad,
Actually, FB correctly deletes fb_sort file used by a transaction after the
transaction completes. However, we have a lot of long-running concurrent
transactions which generate a lot of large fb_sort files. Moreover, when
our customer rebuilt indexes they ran out of system disk space (since
--- In firebird-support@yahoogroups.com, Alec Swan wrote:
>
> Vlad, the large files have fb_sort prefix. But we also see a lot of small
> fb_lock files.
They could be left only if engine was not shutted down correctly.
fb_sort_XXX files left means application was crushed.
fb_lock_XXX f
Cheers Poul, works a treat now
Si
On Jun 3, 2012 12:36 PM, "Poul Dige" wrote:
> **
>
>
> I guess it is because of the precision.
>
> 63.34/100 =0.6334, but casted as decimal(6,2) it will become 0.63 (the
> first number used in the calculation will decide the precision).
>
> 0.63*(33-5) = 0.63*28
Never use double precision for money neither for count something, use it
for measures.
Greetings.
Walter.
On Sat, Jun 2, 2012 at 2:06 PM, Mark Rotteveel wrote:
> **
>
>
> On 2-6-2012 19:47, softdestek wrote:
> > ACCOUNTS.DEBT is double
> > ACCOUNTS.RECEIVABLES is double
> >
> > MY QUERY
> >
Vlad, the large files have fb_sort prefix. But we also see a lot of small
fb_lock files.
Lester, we are a Windows-based shop and most of our customers have FB
databases are under 200MB. There are just a few that have 10-20GB databases.
Our customers need the ability to put those files on a separa
I am sorry for the last post I did not see that Mark already answered it.
Is there online docs for SELECT syntax?
Thank you, Mark.
On Sun, Jun 3, 2012 at 8:59 AM, Alec Swan wrote:
> Thanks, Mark.
>
> I found FB 2.5 SQL Language reference here
> http://www.firebirdsql.org/refdocs/langrefupd25-s
Thanks, Mark.
I found FB 2.5 SQL Language reference here
http://www.firebirdsql.org/refdocs/langrefupd25-select.html but it does
not contain the grammar for the entire SELECT statement, just individual
fragments, such as JOIN, ORDER BY, etc.
Where can I find a comprehensive syntax definition for
On 01/06/12 16:38, Michael Ludwig wrote:
> Follow-up on a recent thread and some pointers to GBAK docs:
>
> Re: Copy of the current db not updating generators
> http://tech.groups.yahoo.com/group/firebird-support/message/118211
>
> Norman Dunbar schrieb am 31.05.2012 um 17:04 (+0100):
>
>> Plus a w
I'll take a look and fix as necessary, thanks again.
Cheers,
Norm.
--
Norman Dunbar
Dunbar IT Consultants Ltd
Registered address:
Thorpe House
61 Richardshaw Lane
Pudsey
West Yorkshire
United Kingdom
LS28 7EL
Company Number: 05132767
I guess it is because of the precision.
63.34/100 =0.6334, but casted as decimal(6,2) it will become 0.63 (the first
number used in the calculation will decide the precision).
0.63*(33-5) = 0.63*28 = 17.64
Kind regards
Poul
Fra: firebird-support@yahoogroups.com [mailto:firebird-support@yahoog
Hi,
The following code is normally within a stored procedure but I have converted
it to execute block with the same results.
In this scenario each salon has a discount on products (33%), they can give
their customers a discount (5%) which is taken from their overall discount
(leaving 28% for s
Alec Swan wrote:
> We are working on tracking those queries down, but fixing them will require
> an upgrade which the customer does not want to do. Moreover, their db size
> is 12GB, so it may not be possible to optimize the queries a lot further.
>
> The customer also ran out of disk space trying
--- In firebird-support@yahoogroups.com, Alec Swan wrote:
>
> Hello,
>
> Our customers are complaining that there are lots of (GBs) temp files
> written by Firebird in temp directory.
Does names of that files have common prefix ?
What OS (Windows, i guess)?
Regards,
Vlad
On 3-6-2012 3:05, Alec Swan wrote:
> I would have never expected a parser token error if the query syntax is
> correct but the plan itself is bad. That would have been a run-time, not
> compile-time error!
>
> And I just verified that what I am saying looks like an FB bug. Here is a
> very simple e
On 3-6-2012 0:27, Dmitry Kuzmenko wrote:
> Hello, Alec!
>
> AS> 2. Changed the query to "A INNER JOIN B ORDER BY X PLAN P", where P is
> the
> AS> plan generated by FB in #1. Received "Unexpected token PLAN" error.
> AS> 3. Change the query to "A INNER JOIN B PLAN P ORDER BY X" - success!
>
>
On 2-6-2012 23:17, Dmitry Kuzmenko wrote:
> Hello, Alec!
>
> AS> The question is why FB complains about PLAN token after ORDER BY clause?
>
> the answer is that PLAN is wrong. ORDER BY in query affects PLAN, it
> will contain PLAN SORT or TABLE ORDER INDEX specification. Your PLAN
> specification
Hi,
Can someone tell me if when making use of a update or insert statement, if
indexes on the MATCHING fields will be used when performing the update
portion?
As an example, the following statement:
UPDATE OR INSERT INTO
CONTROLSALES (SALE_DATE, INTRECNO_CUSTOMER, CASHCREDIT, SALESTOTALEX,
SALE
30 matches
Mail list logo
