Tim,

I started to work on migration of my first application to EDB. I wanted to
migrate programmatically and I used the code published in migration help.
Process stops with AV:
  with Migrator do begin
      SourceDatabase := SourceDatabase;
      SourceDatabase.Session.GetTableNames('Source', SourceTables);
<<<<< AV

Then I included the code of edbmigrate.pas into my code and found that the
procedure TEDBMigrator.SetSourceTables(Value: TStrings) has no compiler
marks i.e. is not reachable or not called within the code. It seems to me
that this is the point of AV.

If I want to migrate with EDBManager I get the message '4.00' is not valid
floating point value.

The last build I can download is Version 1.02 Build 1

Regards
Iztok Lajovic

Iztok,

<< I started to work on migration of my first application to EDB. I wanted
to migrate programmatically and I used the code published in migration help.
Process stops with AV:
  with Migrator do begin
      SourceDatabase := SourceDatabase;
      SourceDatabase.Session.GetTableNames('Source', SourceTables);  <<<<<
AV

Then I included the code of edbmigrate.pas into my code and found that the
procedure TEDBMigrator.SetSourceTables(Value: TStrings) has no compiler
marks i.e. is not reachable or not called within the code. It seems to me
that this is the point of AV. >>

Sorry about that - it's an error in the source code published in the
example.   You need to use:

Migrator.SourceDatabase:=SourceDatabase;
Migrator.DestDatabase:=DestDatabase;

instead right before the:

with Migrator do

line of code.   It should look like this instead:

   Migrator.SourceDatabase:=SourceDatabase;
   Migrator.DestDatabase:=DestDatabase;
   with Migrator do
        begin
        SourceDatabase.Session.GetTableNames('Source',SourceTables);
        OnStatusMessage:=StatusMessage;
        OnProgress:=Progress;
        Execute;
        end;

The way it is currently written, the with block causes a nil to be assigned
to both the SourceDatabase and DestDatabase properties.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

thank you. Now it works.

I have another question. To open DBISAM table I made a shortcut to open
files with .DAT extension with DBSys. When I double clicked to a file, DBSys
opens it at once. If I make shortcut with files with .EDBTlb extension,
EDBMgr starts after double click, but selected table cannot be opened
because EDBMgr does not find proper database. Obviously this information is
stored in catalog file which location is not known when I double click on
table in selected directory.

There is a much longer way to open files with EDBMgr than it is with DBSys.
Is there any possibility to shorten necessary steps to open files?

Regards
Iztok Lajovic

Iztok,

<< I have another question. To open DBISAM table I made a shortcut to open
files with .DAT extension with DBSys. When I double clicked to a file, DBSys
opens it at once. If I make shortcut with files with .EDBTlb extension,
EDBMgr starts after double click, but selected table cannot be opened
because EDBMgr does not find proper database. Obviously this information is
stored in catalog file which location is not known when I double click on
table in selected directory.

There is a much longer way to open files with EDBMgr than it is with DBSys.
Is there any possibility to shorten necessary steps to open files? >>

ElevateDB isn't file-based like DBISAM, so it really isn't possible to open
up tables with a double-click like it was in DBISAM.  All of the information
regarding which tables exist, etc. is stored in the database catalog.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

>
> ElevateDB isn't file-based like DBISAM, so it really isn't possible to open
> up tables with a double-click like it was in DBISAM.  All of the information
> regarding which tables exist, etc. is stored in the database catalog.

Now there's an unforseen productivity blocker.  I regularly open my data files
that way when testing.

Perhaps an '.ini' file or similar in the relevant data directory or somewhere
could point the relevant catalog drive/directory??

EDBMgr could test for the presence of the '.ini' file and use it if there.

Just a thought.

Regards,

Ian


--

Tim,

>>
>> There is a much longer way to open files with EDBMgr than it is with
>> DBSys. Is there any possibility to shorten necessary steps to open files?
>>  >>
>
> ElevateDB isn't file-based like DBISAM, so it really isn't possible to
> open up tables with a double-click like it was in DBISAM.  All of the
> information regarding which tables exist, etc. is stored in the database
> catalog.
>

Yes, I know, but given clicked table directory EDBMgr can search in catalog
hierarchical structure (EDBMgr > session > databases > database > tables >
selected table) how many times this particular file is found.
- If there is only one hit then EDBMgr should open session, database, table
and user should provide necessary information if needed as password etc.
- If there are many hits then EDBMgr should open all elements in
hierarchical structure while elements are common, put the user to choose
appropriate element and in that manner till the table could be opened.

The developers should have as short way to open the table as possible:
- using DBSys one has to make three steps to open the table: select icon
'open table' > choose database (if proposed one is not appropriate) > select
the table.
- using EDMMgr there are nine steps: click to + to open list of sessions >
select session > connect selected session > click to + to open list of
databases > select then database > open the selected database > click to +
to open list of tables > select the table > open selected table.

This only a low level priority suggestion.

Regards
Iztok Lajovic

Ian,

<< Perhaps an '.ini' file or similar in the relevant data directory or
somewhere could point the relevant catalog drive/directory?? >>

There's a lot more to it than that when you bring in user security and
required logins, etc., and frankly, I just don't want to give the impression
to anyone that tables should be opened up like that.  EDB just isn't
designed that way.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Ian,
>
> << Perhaps an '.ini' file or similar in the relevant data directory or
> somewhere could point the relevant catalog drive/directory?? >>
>
> There's a lot more to it than that when you bring in user security and
> required logins, etc., and frankly, I just don't want to give the impression
> to anyone that tables should be opened up like that.  EDB just isn't designed
> that way.

Hi Tim,

   Appreciated, however I think we, you, me and other developers, need a
mechanism that will allow users to forward suspect tables for analysis/repair.
How often have you, in DBISAM, requested somebody to send you the file so you
can have a look?  Certainly It is what I do att when the standard recovery
mechanisms fail at the users site.

   IIUYC then there would seem att to be only one option and that would be to tie
down the users environment so closely that if they need to send me a file I can
plug it into my development environment and access/work on it.

   Anybody else got any thoughts onthe subject?

Regards,

Ian

--

Ian,

<< Appreciated, however I think we, you, me and other developers, need a
mechanism that will allow users to forward suspect tables for
analysis/repair. How often have you, in DBISAM, requested somebody to send
you the file so you can have a look?  Certainly It is what I do att when the
standard recovery mechanisms fail at the users site. >>

Sure, but that's a different issue altogether.  You can send a single
table's files along with the catalog file to another location and that
location can still open the table.  If it tries to open the other tables,
they will open just fine but simply be empty.  Of course, if you have
foreign key constraints defined, then you might not be able to update the
one table with data without possibly having other tables that complete the
foreign key constraints.

<< IIUYC then there would seem att to be only one option and that would be
to tie down the users environment so closely that if they need to send me a
file I can plug it into my development environment and access/work on it. >>

Nah, just do the above and then issue a CREATE DATABASE statement to hook up
their database (and the directory where you copied the catalog and table
files) to your current configuration.  It's two steps:

1) Copy catalog and tables files to a new database directory
2) Issue the CREATE DATABASE

I do it all of the time, and it's easy.

--
Tim Young
Elevate Software
www.elevatesoft.com