I have discovered a problem in DBISAM 4.25 (Build 3). It seems that when a user-defined function is used as the second string in a CONCAT and the result of that function is an empty string,
the CONCAT function uses the result from the prior record.

For example:

SELECT
 CONCAT( MyFunction(Field1) WITH MyFunction(Field2) ) AS Test

If the data is as follows and MyFunction simply returns the value passed to it
Field1, Field2
AAA, BBB
CCC, (empty string)
DDD, (empty string)
EEE, FFF

The query will return:

AAABBB
CCCBBB
DDDBBB
EEEFFF

I can work around this by changing the query as follows:

SELECT
 CONCAT( MyFunction(Field1) WITH IF(MyFunction(Field2)='','',MyFunction(Field2)) ) AS Test

Danny,

<< I have discovered a problem in DBISAM 4.25 (Build 3). It seems that when
a user-defined function is used as the second string in a CONCAT and the
result of that function is an empty string, the CONCAT function uses the
result from the prior record. >>

We're aware of the issue, and hopefully will have a new build by the end of
next week.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Will a new release include a fix for my problem??

Roy Lambert

Roy,

<< Will a new release include a fix for my problem?? >>

Doubtful.  I haven't looked at it yet, but I can almost guarantee you that
my initial response is exactly correct.  You're simply hitting the table
lock file limit.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Doubtful. I haven't looked at it yet, but I can almost guarantee you that
>my initial response is exactly correct. You're simply hitting the table
>lock file limit.

If so either my eyes are misreading my code or DBISAM is breaking the rule about not adding a lock if the table is opened exclusively.

I can check for the existence of tables, is there anyway I can count the locks?

Roy Lambert

Roy,

<< If so either my eyes are misreading my code or DBISAM is breaking the
rule about not adding a lock if the table is opened exclusively.  >>

Checking now....okay, the issue is that the CREATE INDEX statement is a
two-step process, preparation and then execution.  During preparation, the
table is opened shared, not exclusively.  I'll see if the preparation can
open the table exclusively instead, but it may not be able to due to other
issues with retrieving the table metadata.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

Eeek. I use memory tables with randomised names (MDI or threads to prevent "crashes") all over the place. If you can't fix or come up with a workround, I assume major redesigns will be needed.

Roy Lambert

Roy,

<< Eeek. I use memory tables with randomised names (MDI or threads to
prevent "crashes") all over the place. If you can't fix or come up with a
workround, I assume major redesigns will be needed. >>

And you normally create more than 4096 in a single process ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>And you normally create more than 4096 in a single process ?

Yes in TMaN where I'm either testing or resetting the Bayesian filtering.

Roy Lambert

Roy,

<< Yes in TMaN where I'm either testing or resetting the Bayesian filtering.
>>

As mentioned in my other post, unless you're using that many threads, you
really shouldn't need that many in-memory tables.   Try using the current
thread ID instead of the tick count in the table name.  That should help.

--
Tim Young
Elevate Software
www.elevatesoft.com