"Ferenc Nemeth" <ferenc.nemeth@interticket.hu> wrote in message
news:44a38513@newsgroups.borland.com...
> I tried it with a string list too but not good.
You should be specifying the full path to the file. You are not doing that.
You are specifying just the filename alone, so the location of the file is
subject to the calling process's current working directory, which chances
dynamically during the process's lifetime. ALWAYS ALWAYS ALWAYS use full
paths when loading files. If you do not, then one of two things can happen:
1) the file will not be found at all, resulting in a file error
2) worse - the wrong file will be located and sent instead of the desired
file.
Try this instead:
procedure TForm1.TSchGetIniFileCommand(ASender: TIdCommand);
begin
try
ASender.Response.LoadFromFile(ExtractFilePath(Application.ExeName) +
'Server.ini');
except
on E: Exception do
begin
ASender.Response.Clear;
ASender.Response.Text := E.Message;
end;
end;
end;
With that said, I suggest using reply codes in your command responses. They
exist for the specific purpose of allowing the client to detect successes
and failures. If you are already using reply codes, then you should not be
catching the exception at all. Or at least re-throw it after clearing the
Response. This way, TIdCommandHandler's native error handling will
automatically send the Exception.Message to the client, ie:
procedure TForm1.TSchGetIniFileCommand(ASender: TIdCommand);
begin
try
ASender.Response.LoadFromFile(ExtractFilePath(Application.ExeName) +
'Server.ini');
except
ASender.Response.Clear;
raise;
end;
end;
Just make sure to set the TIdCommandHandler's or TIdTCPServer's
ReplyExceptionCode property to a non-zero value to enable the native error
handling behavior.
> Version 9.0.18
That is an old build of Indy 9. Try upgrading to the latest 9.0.50
snapshot.
> There is some commandhandlers working well. Firewall, router blocks
> all. Why OpenWriteBuffer and CloseWriteBuffer solves this problem?
It can't be. All that is doing is writing the outbound data to a memory
buffer, and then writing that buffer to the socket. The data itself is
still the same whether you use write buffering or not.
> Yes of course, the machine has changed, so changed everything. The main
> board, processor, HDD, network card.... only our application server was
> not changed.
That is still not enough to be causing sockets to lose data.
> Sending a telnet command and waiting an answer, but the answer
> is not full like this:
>
> getinifile
> [COMMON]
> (the cursor blinking here)
>
> this is not full, because there is more than 30 line in the ini file.
Obviously not, or else it would have all been sent. Unless the data is
actually sending it, but the client is not reading it all.
Gambit
