Is there any way to get the complete message when DBISAM truncates it?   
For example, this was passed to a TDatabase.RestoreLog event handler:

Database restore: Error during restore of database C:\Documents and  
Settings\All Users\Application Data\Ascendis Software\Ascendis Caller  
ID\2\Db - DBISAM Engine Error # 11013 Access denied to table or backup  
file 'C:\Documents and Settings\All Users\Application Data\Ascen

In this case it's not critical, but it would still be nice to know what  
file DBISAM was trying to access when the problem occurred...

-Bill

Bill,

<< Is there any way to get the complete message when DBISAM truncates it? >>

Unfortunately, no.  DBISAM uses nothing but short strings internally in the
engine itself, so the truncation is implicit in the engine if the string is
larger than 255 characters.

--
Tim Young
Elevate Software
www.elevatesoft.com

Is it as easy as a compiler switch to start using long strings?  Given how  
infrequently errors occur (relative to successful operations, anyway), it  
doesn't seem like performance is a reason not to use them.

Also, given that to keep Microsoft happy the database should live in a  
folder off of
  C:\Documents and Settings\All Users\Application Data\<company  
name>\<program name>\
and given that in some error messages, such as the one given, the above  
path is used twice, that doesn't leave a lot of room!

Maybe this could be implemented in version 5?

Finest regards,
Bill


On Sat, 19 Aug 2006 15:10:25 -0400, Tim Young [Elevate Software]  
<timyoung@elevatesoft.com> wrote:

> Bill,
>
> << Is there any way to get the complete message when DBISAM truncates  
> it? >>
>
> Unfortunately, no.  DBISAM uses nothing but short strings internally in  
> the
> engine itself, so the truncation is implicit in the engine if the string  
> is
> larger than 255 characters.
>

Bill


>Also, given that to keep Microsoft happy the database should live in a
>folder off of
> C:\Documents and Settings\All Users\Application Data\<company
>name>\<program name>\
>and given that in some error messages, such as the one given, the above
>path is used twice, that doesn't leave a lot of room!
>

Why keep M$ happy - they don't keep me happy.

Roy Lambert

Bill,

<< Is it as easy as a compiler switch to start using long strings? >>

Unfortunately, no.  Not at least without some serious testing.

<< Given how infrequently errors occur (relative to successful operations,
anyway), it doesn't seem like performance is a reason not to use them. >>

It's their use (or non-use) elsewhere besides error strings that might have
performance/bug issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

Bill,

<< Maybe this could be implemented in version 5? >>

ElevateDB only uses long ANSI/Wide strings, so this is not an issue with
ElevateDB.

--
Tim Young
Elevate Software
www.elevatesoft.com

Well that's some good news!  Thank you.

Finest regards,
Bill Root
Ascendis Software
http://www.ascendis.com/


On Mon, 21 Aug 2006 15:06:28 -0400, Tim Young [Elevate Software]  
<timyoung@elevatesoft.com> wrote:

> Bill,
>
> << Maybe this could be implemented in version 5? >>
>
> ElevateDB only uses long ANSI/Wide strings, so this is not an issue with
> ElevateDB.