Hi everyone,
The following query works fine when called from the application:
SELECT MBRID,POLNO,PTYPE,BNKDT,AMUNT,
ERROR,RECPT
from PYMT where BNKDT='$sttdt' and BNKDT='$enddt'
However, the following stored procedure (using the same above query) throws
an error:
SET TERM ^ ;
CREATE PROCEDURE
I don't know what your fields are but it looks like you're trying to
store the MBRID - presumably identifier - into a date field for output.
When you just issue a select that will work, but when you use an SP it
fails. Check your code, or cast(MBRID) as date
Alan J Davies
Aldis
On 06/04/2012
Thanks Alan, I'm sure that your are correct. I guess that is what happens
when you don't take a break as you start making silly mistakes.
Much appreciated.
On Fri, Apr 6, 2012 at 1:28 PM, Alan J Davies
alan.dav...@aldis-systems.co.uk wrote:
I don't know what your fields are but it looks like
Hello friends,
I have a strange performance problem with fb 2.5.X. My friend told me
that a program that he uses is working faster when database is on
Windows XP compared to database on Linux. I didn't believe and did some
tests. I can't explain the results to myself. For the tests I've used
This query uses natural for both tables, when I expected it to use an
index for the join.
select *
from table1 t1
join table2 t2 on t2.indexed_char14 starting with t.indexed_char10
where t.unindex_varchar containing 'foo'
This uses an index, so the optimizer knows about it.
select *
from table2
Thanks Dmitry,
You are right. The performance on virtual machine is slower than on real
hardware, but in my case it was the opposite. FB on
VirtualBox(WindowsXP) was working faster than running on the host.
The task in beginning was simple. My friend told me, that his
application is working
