In dbsys I executed a query on a remote table. When I used export to
D:\export.txt the resulting file ended up at the D-drive on the server, not
my local D-drive. I don't even have the D-drive on the server mapped
locally. How did that happen?

When I tried to select another place like D:\admin\export.txt it failed with
an error 11010, because the D-drive on the server doesn't have an admin
folder. The browse button clearly lets you browse locally for a folder.

Perhaps the bug is still there in version 4.x?

Regards
Uffe

Uffe,

<< In dbsys I executed a query on a remote table. When I used export to
D:\export.txt the resulting file ended up at the D-drive on the server, not
my local D-drive. I don't even have the D-drive on the server mapped
locally. How did that happen? >>

This is normal - the IMPORT/EXPORT both occur from the perspective of the
database server, not from the perspective of the client machine.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:757B09BF-6C82-4DB5-B791-FA8B5736C339@news.elevatesoft.com...
>
> This is normal - the IMPORT/EXPORT both occur from the perspective of the
> database server, not from the perspective of the client machine.

But it has a browse button for where to store the generated file, that
browses the clients harddisk !

Uffe Kousgaard wrote:
> "Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
> message
> news:757B09BF-6C82-4DB5-B791-FA8B5736C339@news.elevatesoft.com...
>>
>> This is normal - the IMPORT/EXPORT both occur from the perspective
>> of the database server, not from the perspective of the client
>> machine.
>
> But it has a browse button for where to store the generated file, that
> browses the clients harddisk !

It browse the hard disk of the computer you use. Start it on the server, and
you will see the servers disk. There is no way that the client can access
the server directory structure. For me, that woud be a serious security
hole.

Ralf

Ralf,

<< It browse the hard disk of the computer you use. Start it on the server,
and you will see the servers disk. There is no way that the client can
access the server directory structure. For me, that woud be a serious
security hole. >>

We've had some requests for this, and we may include such functionality in
ElevateDB, but it will be locked down and inaccessible by default.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Ralf Mimoun" <nospam@rad-on.de> wrote in message
news:6BD34BB2-0309-47B4-B349-DEF0860C5CBD@news.elevatesoft.com...
>
> It browse the hard disk of the computer you use. Start it on the server,
> and you will see the servers disk.

Letting the user browse a local disk, when the file will be generated on the
server, is an error in the design. Quite simple. I have reported it, but if
there is no desire to correct bugs, I'll just stop reporting them.

"Uffe Kousgaard" <look_at_www.routeware.dk> wrote on Sat, 25 Feb 2006 01:34:39 +0100



>
>Letting the user browse a local disk, when the file will be generated on the
>server, is an error in the design. Quite simple. I have reported it, but if
>there is no desire to correct bugs, I'll just stop reporting them.
>
>
Uffe


Whether you think it is a bug or not is irrelevant.  You've reported it for v3.30 - old version, no mods, no bug fixes.   It isn't that there is "no desire to correct bugs" it is just that  v4 is the current maintained version - soon (?) v5 will be the current version.

Cheers

Jeff



--
Jeff Cook
Aspect Systems Ltd
Phone: +64-9-424 5388
Skype: jeffcooknz
www.aspect.co.nz

"Jeff Cook" <jeffc@aspect.co.nz> wrote in message
news:BABA89C9-9E83-44EA-BF6E->

> Whether you think it is a bug or not is irrelevant. You've reported it for
v3.30 - old version, no mods, no bug fixes. It isn't that there is "no
desire to correct bugs" it is just that v4 is the current maintained
version - soon (?) v5 will be the current version.

Jeff,

Whatever you think or not think is irrevalent. In my original post I said
the error might still be there in version 4, i.e. I'm perfectly aware 3.30
is not the current version. But as I said, if pointing out bugs is no longer
welcome, I just quit doing it.

I can not say Tim has replied in a proper way and the e-mail was primarily
to him, not you or Ralf.

Regards
Uffe

Uffe,

<< Letting the user browse a local disk, when the file will be generated on
the server, is an error in the design. Quite simple. I have reported it, but
if there is no desire to correct bugs, I'll just stop reporting them. >>

It's not a bug, and I don't appreciate you implying that we don't have any
desire to fix bugs simply because you don't agree with my reply.  There was
nothing improper about my original reply, and we issue new builds all of the
time to fix bugs.

The DBSYS utility uses a local file dialog for specifying the import/export
file names, hence it has no way of knowing about the file system relative to
the database server without having UNC/mapped access to the same file system
that the database server has.

If you want to implement something that works that way, then you can do so
via a server-side procedure in version 4 on the database server.   Just set
it up to accept the import file contents, database name, and table name as
parameters to the server-side procedure, and then run the ImportTable()
method on the file after saving it to disk:

procedure TMyForm.ServerProcedure(Sender: TObject;
 ServerSession: TDBISAMSession; const ProcedureName: String);
var
  TempFileName: string;
  TempTable: TDBISAMTable;
begin
  if (AnsiCompareText(ProcedureName,'ImportText')=0) then
     begin
     with ServerSession do
        begin
        TempTable:=TDBISAMTable.Create(nil);
        try
           with TempTable do
              begin
              SessionName:=ServerSession.SessionName;
              DatabaseName:=RemoteParams.ParamByName('DatabaseName').AsString;
              TableName:=RemoteParams.ParamByName('TableName').AsString;
              RemoteParams.ParamByName('ImportFile').SaveToFile('c:\temp\tempimport.txt');
              ImportTable('c:\temp\tempimport.txt',.......);
              end;
         RemoteParams.Clear;
        end;
     end;
end;

--
Tim Young
Elevate Software
www.elevatesoft.com

I can see what Uffe is saying.  I have been caught out by the inconsistency
myself, when using the C/S version.

If I use dbsys to export data, the Select.., button opens a browser on the
local machine's directory structure but tries to save the file on the
server's directory structure using an inapplicable path.

If I use dbsys to backup data, dbsys automatically concatenates the current
directory of the local machine with a generated file name.  You don't even
get to see this pathname unless you click on the Backup Information tab.
The backup then fails with the cryptic messages...

There was an error backing up the database

An unknown operating system error 11047 occurred...

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!

So, the only way I have found of getting data off the server onto my local
machine using dbsys is to use the reverse engineer facility.  Running a query
then saving the result to a file on disk won't do it, because the Local
option is greyed out.

--Bill Sparrow--