Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 10 total
Thread DBISAM v3.30 ImportTable works in lcoal mode but not in C/S
Thu, Jun 14 2007 5:04 PMPermanent Link

"Jeff Cook"
Kia Orana

I have a problem with a program that imports a CSV file.  It has been
working for ages in local mode but it has now fallen over in C/S mode.  I
suspect that we've been lucky up to now as often our small sites using C/S
have the admin person working on the same machine as the DBISAM server using
a local client - which is working fine.

I create a memory table for the import like this:-

     SQL.Clear;
     SQL.Add('DROP TABLE IF EXISTS MEMORY Import;');
     SQL.Add('CREATE TABLE IF NOT EXISTS MEMORY Import');
     SQL.Add('(  "Sequence" AUTOINC NOT NULL,');
     SQL.Add('   "TenantCode" CHARACTER(4),');
     SQL.Add('   "TransDate" DATE,');
     SQL.Add('   "SerialNo" CHARACTER(12),');
     SQL.Add('   "TransactionCode" CHARACTER(3),');
     SQL.Add('   "Amount" MONEY,');
     SQL.Add('   "Particulars" CHARACTER(12),');
     SQL.Add('   "Analysis" CHARACTER(12),');
     SQL.Add('   "Reference" CHARACTER(12),');
     SQL.Add('   "OtherParty" CHARACTER(20),');
....etc.

The import process ia like this:-

       try
         with tblImport do
         begin {Account Number, Name, Date, Amount, Particulars, Code,
Reference,
                                          OtherParty, Tran Type, Balance}
           with slIncomingFields do
           begin
             Add('AccountNo');
             Add('Ignore1');
             Add('TransDate');
             Add('Amount');
             Add('Particulars');
             Add('Analysis');
             Add('Reference');
             Add('OtherParty');
             Add('TransactionCode');
             Add('CharAmount');
           end;
           if exists then showmessage('Exists') else showmessage('Nope!
Doesn''t exist.');
           ImportTable(sWorkFileName, ',', False, slIncomingFields,
'yyyy/mm/dd');
....
   except
     on E: Exception do
     begin
       Beep;
       if (E is EDBISAMEngineError) then
         MessageDlg('Unable to Import!'#13#10#13#10'File: ' + sFileName
           + #13#10#13#10'DBISAM Error #'
           + IntToStr(EDBISAMEngineError(E).ErrorCode), mtError, [mbOK], 0)
       else
         MessageDlg('Unable to Import!'#13#10#13#10'File: ' + sFileName,
mtError, [mbOK], 0);
       Screen.Cursor := crDefault;
       Exit;
     end;
   end;

AND it is giving me a "DBISAM_OSENOENT (11010) Table '<TableName>' does not
exist" exception.
BUT when I add the debugging code to show the existence of the table before
the ImportTable, it says that it does exist!

H0pefully there is a simple solution?

Kia Manuia

Jeff

--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
The Cooks Ltd
www.cookislandsoasis.com

Fri, Jun 15 2007 3:50 AMPermanent Link

Arnd Baranowski
Kia,

did you check that the filename/directory information reflects the
server filename/directory information? If not then this it. In CS mode
you have to use the servers filename/directory information.

Arnd

Jeff Cook wrote:

> Kia Orana
>
> I have a problem with a program that imports a CSV file.  It has been
> working for ages in local mode but it has now fallen over in C/S mode.  I
> suspect that we've been lucky up to now as often our small sites using C/S
> have the admin person working on the same machine as the DBISAM server using
> a local client - which is working fine.
>
> I create a memory table for the import like this:-
>
>       SQL.Clear;
>       SQL.Add('DROP TABLE IF EXISTS MEMORY Import;');
>       SQL.Add('CREATE TABLE IF NOT EXISTS MEMORY Import');
>       SQL.Add('(  "Sequence" AUTOINC NOT NULL,');
>       SQL.Add('   "TenantCode" CHARACTER(4),');
>       SQL.Add('   "TransDate" DATE,');
>       SQL.Add('   "SerialNo" CHARACTER(12),');
>       SQL.Add('   "TransactionCode" CHARACTER(3),');
>       SQL.Add('   "Amount" MONEY,');
>       SQL.Add('   "Particulars" CHARACTER(12),');
>       SQL.Add('   "Analysis" CHARACTER(12),');
>       SQL.Add('   "Reference" CHARACTER(12),');
>       SQL.Add('   "OtherParty" CHARACTER(20),');
> ...etc.
>
> The import process ia like this:-
>
>         try
>           with tblImport do
>           begin {Account Number, Name, Date, Amount, Particulars, Code,
> Reference,
>                                            OtherParty, Tran Type, Balance}
>             with slIncomingFields do
>             begin
>               Add('AccountNo');
>               Add('Ignore1');
>               Add('TransDate');
>               Add('Amount');
>               Add('Particulars');
>               Add('Analysis');
>               Add('Reference');
>               Add('OtherParty');
>               Add('TransactionCode');
>               Add('CharAmount');
>             end;
>             if exists then showmessage('Exists') else showmessage('Nope!
> Doesn''t exist.');
>             ImportTable(sWorkFileName, ',', False, slIncomingFields,
> 'yyyy/mm/dd');
> ...
>     except
>       on E: Exception do
>       begin
>         Beep;
>         if (E is EDBISAMEngineError) then
>           MessageDlg('Unable to Import!'#13#10#13#10'File: ' + sFileName
>             + #13#10#13#10'DBISAM Error #'
>             + IntToStr(EDBISAMEngineError(E).ErrorCode), mtError, [mbOK], 0)
>         else
>           MessageDlg('Unable to Import!'#13#10#13#10'File: ' + sFileName,
> mtError, [mbOK], 0);
>         Screen.Cursor := crDefault;
>         Exit;
>       end;
>     end;
>
> AND it is giving me a "DBISAM_OSENOENT (11010) Table '<TableName>' does not
> exist" exception.
> BUT when I add the debugging code to show the existence of the table before
> the ImportTable, it says that it does exist!
>
> H0pefully there is a simple solution?
>
> Kia Manuia
>
> Jeff
>
Fri, Jun 15 2007 4:14 PMPermanent Link

"Jeff Cook"
Hi Arnd

In this case the table is a memory table and MyTable.Exists returns True
immediately before the MyTable.ImportTable(...), yet I get the error
"DBISAM_OSENOENT (11010) Table '<TableName>' does not  exist" on executing
the ImportTable.

As this is a memory table, I can't see how CS mode or not makes any
difference - but it does.  Also, all the non memory tables (and memory
tables in other procedures) and all the queries work correctly for dozens of
tables on many, many forms.

It seems seriously weird to me.

Cheers and thanks for you time

Jeff

"Arnd Baranowski" <baranowski@oculeus.de> wrote in message
news:96674346-D540-4CB0-B3E8-0AAD8FCCBEDC@news.elevatesoft.com...
> Kia,
>
> did you check that the filename/directory information reflects the server
> filename/directory information? If not then this it. In CS mode you have
> to use the servers filename/directory information.
>
> Arnd
>
> Jeff Cook wrote:
>
>> Kia Orana
>>
>> I have a problem with a program that imports a CSV file.  It has been
>> working for ages in local mode but it has now fallen over in C/S mode.  I
>> suspect that we've been lucky up to now as often our small sites using
>> C/S have the admin person working on the same machine as the DBISAM
>> server using a local client - which is working fine.
<<snip>>

Fri, Jun 15 2007 4:20 PMPermanent Link

Arnd Baranowski
Kia,

I am not talking about the memory table. It is the following I am
referring to

ImportTable(sWorkFileName, ',', False, slIncomingFields,
'yyyy/mm/dd');

"sWorkFileName" in CS mode works in relation to the server directories
and not in relation to the client directories.

Arnd

Jeff Cook wrote:
> Hi Arnd
>
> In this case the table is a memory table and MyTable.Exists returns True
> immediately before the MyTable.ImportTable(...), yet I get the error
> "DBISAM_OSENOENT (11010) Table '<TableName>' does not  exist" on executing
> the ImportTable.
>
> As this is a memory table, I can't see how CS mode or not makes any
> difference - but it does.  Also, all the non memory tables (and memory
> tables in other procedures) and all the queries work correctly for dozens of
> tables on many, many forms.
>
> It seems seriously weird to me.
>
> Cheers and thanks for you time
>
> Jeff
>
> "Arnd Baranowski" <baranowski@oculeus.de> wrote in message
> news:96674346-D540-4CB0-B3E8-0AAD8FCCBEDC@news.elevatesoft.com...
>
>>Kia,
>>
>>did you check that the filename/directory information reflects the server
>>filename/directory information? If not then this it. In CS mode you have
>>to use the servers filename/directory information.
>>
>>Arnd
>>
>>Jeff Cook wrote:
>>
>>
>>>Kia Orana
>>>
>>>I have a problem with a program that imports a CSV file.  It has been
>>>working for ages in local mode but it has now fallen over in C/S mode.  I
>>>suspect that we've been lucky up to now as often our small sites using
>>>C/S have the admin person working on the same machine as the DBISAM
>>>server using a local client - which is working fine.
>
> <<snip>>
>
>
Fri, Jun 15 2007 5:18 PMPermanent Link

"Jeff Cook"
Hi Arnd

"Arnd Baranowski" <baranowski@oculeus.de> wrote in message
news:1D26A3D8-6366-43D6-BDC5-AE50BEA84462@news.elevatesoft.com...
> Kia,
>
> I am not talking about the memory table. It is the following I am
> referring to
>
> ImportTable(sWorkFileName, ',', False, slIncomingFields,
> 'yyyy/mm/dd');
>
> "sWorkFileName" in CS mode works in relation to the server directories and
> not in relation to the client directories.
>

Really? But I'm addressing the sWorkFileName using a fully qualified local
filename.  It seems nutty that I have to put import file onto the server in
order to import it!  If I have to do this then there is 99% chance that the
remote client won't be alloed to write directly to the server anyway.

I'd appreciate Tim's input on this.

Cheers

Jeff

Sat, Jun 16 2007 7:01 AMPermanent Link

Arnd Baranowski
Hi Jeff,

It is like that.

How should it work with your setup. The server shall open the importfile
directly on your client via LAN/WAN, getting all client file rights on
the fly, connects to the client and then translates the local filename
to something that tells him where the file is.

If you want your setup to work in CS Mode you have to do the following.
Generate a local memory table in a local session. Import the file and
stream the table to a remote server session memory table.

Arnd

Jeff Cook wrote:

> Hi Arnd
>
> "Arnd Baranowski" <baranowski@oculeus.de> wrote in message
> news:1D26A3D8-6366-43D6-BDC5-AE50BEA84462@news.elevatesoft.com...
>
>>Kia,
>>
>>I am not talking about the memory table. It is the following I am
>>referring to
>>
>>ImportTable(sWorkFileName, ',', False, slIncomingFields,
>>'yyyy/mm/dd');
>>
>>"sWorkFileName" in CS mode works in relation to the server directories and
>>not in relation to the client directories.
>>
>
>
> Really? But I'm addressing the sWorkFileName using a fully qualified local
> filename.  It seems nutty that I have to put import file onto the server in
> order to import it!  If I have to do this then there is 99% chance that the
> remote client won't be alloed to write directly to the server anyway.
>
> I'd appreciate Tim's input on this.
>
> Cheers
>
> Jeff
>
>
Sat, Jun 16 2007 7:45 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jeff,

<< Really? But I'm addressing the sWorkFileName using a fully qualified
local filename.  It seems nutty that I have to put import file onto the
server in order to import it! >>

That is the case here.  Any external files (backups, imports) on the
database server must be referenced in the backup or import from the
perspective of the database server, not the client application or
workstation.

<< If I have to do this then there is 99% chance that the remote client
won't be alloed to write directly to the server anyway. >>

Which is one of the reasons why we don't allow large file transfers to the
done in this manner.  Someone could very easily, and most importantly
quickly, fill up the server's drive with crap as a sort of crude
denial-of-service attack.

--
Tim Young
Elevate Software
www.elevatesoft.com

Mon, Jun 18 2007 5:26 PMPermanent Link

"Jeff Cook"
Thanks Tim and Arnd

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:D8C7D32C-AB16-4D90-A2FE-2560DC372E4E@news.elevatesoft.com...
<snip>
> Which is one of the reasons why we don't allow large file transfers to the
> done in this manner.  Someone could very easily, and most importantly
> quickly, fill up the server's drive with crap as a sort of crude
> denial-of-service attack.
>

Well I understand the reasoning, but I have the following work around which
doesn't require me to write any server side code (something I have avoided
until now):-

if Copy(sWorkFileName, 1, 2) <> '\\' then
  sWorkfileName :=
     AnsiReplaceStr('\\' + Common.ComputerName + '\' + sWorkFileName, ':',
'');
ImportTable(sWorkFileName, ',', False, slIncomingFields, 'yyyy/mm/dd');

Which seems to work OK and just requires that the client puts the data in a
folder that is shared on the network.

Is this going to work everywhere?

And is it not just as liable for "fill up the server's drive with crap"
attacks?

Cheers

Jeff


Mon, Jun 18 2007 6:12 PMPermanent Link

"Jeff Cook"
Tim

One of the reasons it has taken me to so long to analyse this problem is
what I believe is a misleading error message.  I got the error
"DBISAM_OSENOENT (11010) Table '<TableName>' does not  exist" when the table
really did exist and it was actually the import text file that didn't exist.

I realise that I'm working on an ancient version (v3.30) - but it would be
nice to think that later versions gave a more useful message.

Cheers

Jeff
--
Jeff Cook
Aspect Systems Ltd
www.aspect.co.nz
+
The Cooks Ltd
www.cookislandsoasis.com

Tue, Jun 19 2007 7:58 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jeff,

<< One of the reasons it has taken me to so long to analyse this problem is
what I believe is a misleading error message.  I got the error
"DBISAM_OSENOENT (11010) Table '<TableName>' does not  exist" when the table
really did exist and it was actually the import text file that didn't exist.
>>

I know.  Unfortunately, it's an architecture thing with 3.x - all of the
file I/O goes through the same code, and the error message code assumes that
the files being opened are tables.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image