Bill,

<< HOWEVER, if I choose to reverse engineer the table, and tick "Include
code to add existing data", then the browse dialog that opens really does
let me choose a folder and save the SQL and data into a local file! >>

I understand, however it's simply an issue of performance.  Only allowing
for local files with respect to import/export would severely hamper the
performance of both operations with the database server.
Reverse-engineering is part of DBSYS only, however, and is not
performance-critical.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

I was composing my reply to that message, when I suddenly wondered if I had
missed out on something.  

> Only allowing for local files with respect to import/export would severely
> hamper the performance of both operations with the database server.

The word "only" seems to change the meaning of what is being discussed.  It
is as if you are saying "local and remote files are available for this
feature, and restricting it to only local would restrict performance".  As
far as I can see only remote files are available.

Assuming only remote files are available, I think there are three issues
here.

a) When the server is the other side of the country, and I don't have remote
access to its files, how do I perform an import/export from where I am
sitting and get hold of the data?  If the answer is "write something yourself
instead of trying to use DBSYS", then I can live with that.

b) Could you not tidy up the user interface of the import/export and
backup/restore features of DBSYS so that, when they are processing data on a
remote server, they don't present a browse dialog that browses the local hard
disk, which simply confuses things.  

c) When using the backup facility of DBSYS, it generates a backup file name
for you.  The location of this file is in the most recently accessed
directory on the local hard disk.  Unless the server also has an identical
directory, the backup is guaranteed to fail.

--Bill Sparrow--

Bill Sparrow wrote:
....
> b) Could you not tidy up the user interface of the import/export and
> backup/restore features of DBSYS so that, when they are processing
> data on a remote server, they don't present a browse dialog that
> browses the local hard disk, which simply confuses things.

Even that is not easy. The DBISAM server can run with another user account
than the one you use. And then, you can run into serious trouble trying to
save a file in a directory the server can't access - or even a directory
that points to a very different location from the servers user point of
view.

> c) When using the backup facility of DBSYS, it generates a backup
> file name for you.  The location of this file is in the most recently
> accessed directory on the local hard disk.  Unless the server also
> has an identical directory, the backup is guaranteed to fail.

What else should DBSYS do?

Ralf

> Even that is not easy.

OK, so I should have left out the word "remote", to cover that case as well.
What I am saying is simply that the user interface should not let the user
browse the local computer if the result is doomed to failure.


> What else should DBSYS do?

If running against a server, DBSYS should ask you where you want to store the
file.  It should warn you that the path you specify must be a valid path as
seen from the server process.

--Bill Sparrow--

Bill Sparrow wrote:
>> Even that is not easy.
>
> OK, so I should have left out the word "remote", to cover that case
> as well. What I am saying is simply that the user interface should
> not let the user browse the local computer if the result is doomed to
> failure.

Sorry, but I disagree. DBSYS is _not_ an end user tool. It's for
professionals, for people who know what they do. I also don't think that
Delphi is evil or buggy just because I can write an application that deletes
every file it can get a hold of right after start.

....
>> What else should DBSYS do?
>
> If running against a server, DBSYS should ask you where you want to
> store the file.  It should warn you that the path you specify must be
> a valid path as seen from the server process.

For me, a simple label somewhere on that dialog would be more than enough.
It's a very small fact that I have to remember. And as I wrote: it does
_not_ help to detect a remote access for that warning. The same problems can
occur when you start dbsys on the server machine.

Ralf

"Ralf Mimoun" <nospam@rad-on.de> wrote in message
news:56BADE8E-A3BF-417C-8280-EB0336199A4C@news.elevatesoft.com...
>
> Sorry, but I disagree. DBSYS is _not_ an end user tool. It's for
> professionals, for people who know what they do.

Well, in that case I'm so sorry, that I had never used the export method in
DBISAM before I used it in DBSYS. Of course it is my fault that I only knew
the other 90% of DBISAM.

> I also don't think that Delphi is evil or buggy just because I can write
> an application that deletes every file it can get a hold of right after
> start.

Writing your own applications is not the same as running someone else's. Not
at all. Any professional would know that.

Regards
Uffe

Calm down Ralf!  I think we are on the same side here.

I too think that if sending the import/export data between the server process
and the client process is something Tim does not want to add to DBSYS, then a
simple label on the dialog warning of the situation would be reasonable
compromise.

> it does _not_ help to detect a remote access for that warning.

I was using the word "remote" in the same sense that DBSYS uses it in the
user interface.  In the table open dialog the choice is between "Local
(Single/Mulituser)" and "Remote (Client/server)".  If DBSYS is accessing the
data via local file access then the local browser is always applicable.  If
DBSYS is accessing the data via a server, then the local file browser may not
be applicable, and there should be a warning.

Are you suggesting that, because we are professionals who know what we are
doing, we should refrain from pointing out improvements that can be made in
the tools we use?


Let's see what Tim has to say in answer to my posting
"Thu, 2 Mar 2006 18:12 +0000 (GMT Standard Time)"

--Bill Sparrow--

Bill Sparrow wrote:
....
> Are you suggesting that, because we are professionals who know what
> we are doing, we should refrain from pointing out improvements that
> can be made in the tools we use?

No, absolutely not! But the title of this thread and the postings are
containing the words "bug", "design error" etc more than once. For me, it is
not a bug or a design error, that's all.

Ralf

Bill,

<< The word "only" seems to change the meaning of what is being discussed.
It  is as if you are saying "local and remote files are available for this
feature, and restricting it to only local would restrict performance".  As
far as I can see only remote files are available. >>

No, I'm saying that if one changed it so that DBSYS only dealt with local
files period, which is what was being asked, then it would be a performance
issue.  Nothing more, nothing less.  I'm only going by what Uffe stated he
wanted.

<< b) Could you not tidy up the user interface of the import/export and
backup/restore features of DBSYS so that, when they are processing data on a
remote server, they don't present a browse dialog that browses the local
hard disk, which simply confuses things. >>

First of all, there will be no more 3.x modifications at all.  That version
if 5 years old and needs to be mothballed.  As for 4.x, yes, these things
could be put in place, however they are not particularly important at this
time given that we need to finish up ElevateDB, which has a completely
different utility and database manager altogether.  It will most likely be
addressed with ElevateDB through publishing the server-side file system (see
below).

<< c) When using the backup facility of DBSYS, it generates a backup file
name for you.  The location of this file is in the most recently accessed
directory on the local hard disk.  Unless the server also has an identical
directory, the backup is guaranteed to fail. >>

I understand.  But again, the only option here is to disable the backup for
remote connections, which precludes situations where one simply wants to do
a backup with DBSYS when the database server is on the same machine.

Basically, as stated earlier, the only way to truly make all of this work is
to publish the server-side directories and files to the client.  This may or
may not be desirable and would have to be controlled, however it is also
something that is not going to happen particularly soon with 4.x due to the
nature of the changes.

--
Tim Young
Elevate Software
www.elevatesoft.com

Firstly, I should apologise for hijacking the thread.  I'm actually
discussing 4.x but forgot to tell everybody!  I've now changed the subject
line in this posting.  Perhaps I should have started a new thread?

Secondly, my level of expectation appears to be lower than what you ascribe
to Uffe.  What I was advocating is that the user interface should reflect the
capabilities that exist, rather than that you should enhance the
capabilities.  After reading what has been said about the situation, I now
think the modifications that would fit the bill are:-

In the Import/Export dialog, add a label warning that the path should be
specified as seen from the server, if accessing server-based data.  Perhaps
also mentioning that a local file browser is provided as a convenience for
those cases where DBSYS is running on the same machine as the server, or
local file access is being used.

In the Backup/Restore dialog, do the same, and also force the user to visit
the tab where the file path is displayed, so that they can see if the
generated path is valid.

I say "was advocating" because I had forgotten how close we are to a release
of ElevateDB.  Since this is an issue that only affects developers who come
across it for the first time, the number affected will presumably
dramatically diminish some time "real soon now".  8-)

> ...ElevateDB, which has a completely different utility and database manager
> altogether.  

I had forgotten that!


> It will most likely be addressed with ElevateDB through publishing the
> server-side file system

An intriguing thought.


> the only option here is to disable the backup for remote connections,

Definitely not what I had in mind!

> which precludes situations where one simply wants to do
> a backup with DBSYS when the database server is on the same machine.

More than that - I find it extremely useful to be able to use DBSYS to backup
the data when I am about to do some table restructuring on a server that is
several miles away.  So long as I can remember where I put the file and what
I called it, I should be able to restore the database if it all went pear
shaped.

--Bill Sparrow--