Hi,

I am trying to backup a local database that is open and when I call the
database component's Backup method I get an EDBIsamEngine error #11010 -
telling me that the table is not found. This table is a temporary table
created by DBIsam and I can see it in the directory I st for the PrivateDir
property of the session.

Any idea what I am doing wrong?

Ron.

Ron,

<< I am trying to backup a local database that is open and when I call the
database component's Backup method I get an EDBIsamEngine error #11010 -
telling me that the table is not found. This table is a temporary table
created by DBIsam and I can see it in the directory I st for the PrivateDir
property of the session. >>

Answered via email:

<< I have an application using a local database that works fine - except
when I call the TDBIsamDatabase.Backup method - where I get an error 11010
telling me that one of the temporary files does not exist. I am looking at
the privatedir defined in the session and I can see the
file there...  >>

Backups don't use temporary files.  What is the exact error message that you
are getting ?  Also, what version of DBISAM are you using ?

Tim Young
Elevate Software
www.elevatesoft.com

> << I have an application using a local database that works fine - except
> when I call the TDBIsamDatabase.Backup method - where I get an error 11010
> telling me that one of the temporary files does not exist. I am looking at
> the privatedir defined in the session and I can see the
> file there...  >>
>
> Backups don't use temporary files.  What is the exact error message that
> you
> are getting ?  Also, what version of DBISAM are you using ?
>

Version 4.24 - I see the error when runnning from the IDE (D7) and the
exception is captured - I do not have the exact syntax now - but it was the
error number mentioned and a numeric table name (31003 or something) which
is one of the private DBIsam files.

Anyway, I solved it by creating a new separate TDBIsamSession and
TDBIsamDatabase pointing to the same local directory and doing the backup
from there.

Before I was using either an open database used by my application on a new
database component using the same session name.

It is solved for me using this method - but I am still not sure why it
happened. I guess it could be because I was using the session's
GetTableNames method to get all the tables for the database - but it seems
rather strange to me that the method will return the names of temporary
tables.

Ron.


> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Ron,

<< It is solved for me using this method - but I am still not sure why it
happened. I guess it could be because I was using the session's
GetTableNames method to get all the tables for the database - but it seems
rather strange to me that the method will return the names of temporary
tables. >>

Do you have the session's private directory set to the same as the database
directory ?  Or, are there any temporary tables present in the database
directory ?  If so, then it could simply be that there are temporary tables
present with missing .blb files, which would cause the kind of error that
you described if they were attempted to be opened by the backup process
because you included them in the list of tables to back up.

--
Tim Young
Elevate Software
www.elevatesoft.com

http://www.bitogo.com/infopath/index.html
"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:B4996EB0-EBE1-400A-922D-D886158FE0AB@news.elevatesoft.com...
> Ron,
>
>
> Do you have the session's private directory set to the same as the
> database directory ?  Or, are there any temporary tables present in the
> database directory ?  If so, then it could simply be that there are
> temporary tables present with missing .blb files, which would cause the
> kind of error that you described if they were attempted to be opened by
> the backup process because you included them in the list of tables to back
> up.

No, the settings were:

Database Directory - $EXE$\FDATDB
PrivateDir - $EXE$\TEMP

Where $EXE$ is the location of the application.

As I said - I fixed it by using a different session and database component -
but it is still rather strange that it happened.

Ron.


>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Ron,

<< No, the settings were:

Database Directory - $EXE$\FDATDB
PrivateDir - $EXE$\TEMP

Where $EXE$ is the location of the application. >>

I understand, but you said:

"but it seems rather strange to me that the method will return the names of
temporary tables."

which indicated to me that there were temporary table names showing up when
you called GetTableNames.  Was this not the case ?

--
Tim Young
Elevate Software
www.elevatesoft.com

> Database Directory - $EXE$\FDATDB
> PrivateDir - $EXE$\TEMP
>
> Where $EXE$ is the location of the application. >>
>
> I understand, but you said:
>
> "but it seems rather strange to me that the method will return the names
> of temporary tables."
>
> which indicated to me that there were temporary table names showing up
> when you called GetTableNames.  Was this not the case ?
>

I did not check - I just passed the stiring list results of this call to the
Backup function as the last parameter - and got the error message about the
(temporary) file name not found - so I assumed that this could be the
reason.

Ron.

Ron,

<< I did not check - I just passed the stiring list results of this call to
the Backup function as the last parameter - and got the error message about
the (temporary) file name not found - so I assumed that this could be the
reason. >>

Okay, are you setting the TDBISAMEngine.CreateTempTablesInDatabase property
to True anywhere in your application ?

http://www.elevatesoft.com/dbisam4d5_tdbisamengine_createtemptablesindatabase.htm

If so, then that might account for temporary tables showing up in your
database directory.  That, and possibly having your session's PrivateDir
property set to the database directory or left blank, which will cause it to
use the current working directory.

--
Tim Young
Elevate Software
www.elevatesoft.com