Hi,

In some of my applications, I have had the need to transfer some of the
data from a clients to my own computer for debugging. (Truth be told,
this happens on almost a weekly basis for some of my clients).

As some of these applications have databases that exceed into Gigabytes
of space, transferring all the datafiles isn't really an option. As
such, I normally only transfer just the tables I need to debug instead
of the entire data.

I'm aware recently that this could pose a problem in EDB if the
structure of the catalog is different on my working PC as compared to
that of my end user.

Am I right / safe in assuming that providing the catalog is the same for
my end user as myself, that a simple copying of the tables I need to my
computer over the existing tables is all I need to accomplish this task,
or am I looking for trouble?

Also - in Version 3 I've heard rumors that it may become a single file
database. Will we have the option for either/or, or will version 3 limit
me to having to copy the entire database everytime I want to do some
debugging (unless I write procedures to export some files to csv, and
import them my end)?

Cheers

Adam.

Adam

>Am I right / safe in assuming that providing the catalog is the same for
>my end user as myself, that a simple copying of the tables I need to my
>computer over the existing tables is all I need to accomplish this task,
>or am I looking for trouble?

Theoretically you are correct, however, if you don't need the data in the other tables get them to send just the tables you want and their catalog. ElevateDB will create empty tables on disk for the missing ones and you can then be sure of a match.

Can't answer on V3

Roy Lambert [Team Elevate]

Adam H.

A couple of other things to consider:

1. Use of the EXPORT TABLE SQL statement in EDB, which allows single tables to be exported as files which can then be re-imported. If the exported files are saved to a shared STORE both the export and import processes can be automated with an EDB Procedure / Job.

2. Use of PUBLISH:

Publish the clients database, but only publish those tables you want to compare/work with.
Periodically run a job on the client to:

* Save updates.
* Copy the update file from a store on their computer to some store you can access easily.

Have a job on your computer to Load Updates from this update file.

All that will get passed around are the updates for  those tables you are comparing, so the file size is minimized. You can also set Compression-levels for the update files ... to further minimize data traffic.

Either way EDB can automate the whole process removing a lot of the legwork.

Hi Roy,

> Theoretically you are correct, however, if you don't need the data in the other tables get them to send just the tables you want and their catalog. ElevateDB will create empty tables on disk for the missing ones and you can then be sure of a match.
>
> Can't answer on V3

Good call regarding the catalog Roy! Something for to keep in mind. I do
like the idea that it will automatically create tables that don't exist.
Cheers!

Adam.

Hi Adam...

> A couple of other things to consider:
>
> 1. Use of the EXPORT TABLE SQL statement in EDB, which allows single tables to be exported as files which can then be re-imported. If the exported files are saved to a shared STORE both the export and import processes can be automated with an EDB Procedure / Job.
>
> 2. Use of PUBLISH:
>
> Publish the clients database, but only publish those tables you want to compare/work with.
> Periodically run a job on the client to:
>
>   * Save updates.
>   * Copy the update file from a store on their computer to some store you can access easily.
>
> Have a job on your computer to Load Updates from this update file.
>
> All that will get passed around are the updates for  those tables you are comparing, so the file size is minimized. You can also set Compression-levels for the update files ... to further minimize data traffic.
>
> Either way EDB can automate the whole process removing a lot of the legwork.

Thanks for those ideas. Exporting the table and importing could be a
good option. Not quite as simple as a copy/paste - but doable.

As for PUBLISH - I may need to make myself familiar with the PUBLISH
feature that you've mentioned Adam. Not something I've come across or
used yet.

Cheers for that

Adam.

Adam


>As for PUBLISH - I may need to make myself familiar with the PUBLISH
>feature that you've mentioned Adam. Not something I've come across or
>used yet.

PUBLISH is a great feature mainly intended to support database replication. I don't think it will be of use in the scenario you described since its unlikely that you want to continuously keep your database synced to your customers.

Roy Lambert [Team Elevate]

>>PUBLISH is a great feature mainly intended to support database replication.

Yes, but it is also brilliant to hack with, as it creates UPDATE files which you can use in a wide variety of ways.

>>I don't think it will be of use in the scenario you described since its unlikely that you want to continuously keep your >>database synced to your customers.

I think Adam could use it for roughly what he needs with a bit of tweeking ... particularly limiting the range of tables for which updates are loaded / saved by using the PUBLISH TABLES keyword.

Just an idea.

Hi Gentlemen,

Thanks for the info. Publish... while it may not be designed for what I
want, it looks like it could come in very handy for some other
operations at a later date!

Thanks very much.

Cheers

Adam.

Adam,

<< Am I right / safe in assuming that providing the catalog is the same for
my end user as myself, that a simple copying of the tables I need to my
computer over the existing tables is all I need to accomplish this task, or
am I looking for trouble? >>

Yes, that will be safe as long as the basic structure of the tables are the
same (at least for the tables that you're interested in, they don't all have
to match, just the ones that you want to open and look at the data).

<< Also - in Version 3 I've heard rumors that it may become a single file
database. Will we have the option for either/or, or will version 3 limit me
to having to copy the entire database everytime I want to do some debugging
(unless I write procedures to export some files to csv, and import them my
end)? >>

Being single file, there's no way to just separate out certain bits, so yes,
you'll have to always copy the entire database.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com