Error 30031 - Server returned an error - is ambigu (wodSFTP / wodSFTP.NET / wodSFTPdll)

We are getting an error 30031 from a server, but there is no indication what is causing the error. What kinds of things can cause this? Where do we turn to find the problem?

Thanks.

Steve,

yes, we made a mistake for not separating server-related errors, and now is too late to go back.

Anyway, if you can use events, in Done event you will get full description of the error - can you check there?

Steve,

yes, we made a mistake for not separating server-related errors, and now is too late to go back.

Anyway, if you can use events, in Done event you will get full description of the error - can you check there?

Hi,

I'd like to revive this topic. Recently we got such a problem. We use FtpDLX in one of our apps for synchronous connections against (excellent BTW) Titan FTP server. Digging in the server logs I found that techie did a mistake when installing - he swapped local and remote dirs definitions in the setup. So it's clear, however it's pitty that I wasn't able to find that in the client log.
At the start our client (after successfull connection of course) calls .ListNames, where we get 30031 in this case. As we are writing info to the log after this, we missed info what exactly happened.

It's easy to us to workaround it, we'll just write the current configuration to the log before calling .ListNames method. I'm writing this just because it's easy way how to reproduce such event AND because we don't use Done event so we won't get additional info you mentioned before. It would help us if you could try to improve this error event.

Miker

Miker,

yes, I agree, but how? Remember - we cannot change the interface, and we cannot change behavior for current users.

Do you have any ideas how to make improvement but still to work for all previous versions too?

Kreso

Miker,
yes, I agree, but how? Remember - we cannot change the interface, and we cannot change behavior for current users.
Kreso

Hmm, understand.
What about to add some property holding server side response for a last action? Question which action it was this response is related to could be answered as that failed one (if one don't care about error handling and don't know which action failed, then he don't need this feature). It shouldn't break any backward compatibility IMHO. Maybe it come handy in another cases, too ... In fact all I need is to get server error code, so it can be long data type.

Of course I don't see bowels of the component, so I'm only guessing how I'd try to get out of it ...

Mike

Miker,

best thing would be of course to separate each message to new one, but that would break current functionality. Everything else is just workaround and is not nice solution.

That's why we moved it aside 'as is'. If we release version 3.0 with new interface, we'll defenitely change this, but until that time I'm affraid not much can be done.

Kreso

Miker,
best thing would be of course to separate each message to new one, but that would break current functionality. Everything else is just workaround and is not nice solution.
Kreso

Agree completely. You just asked me for an opinion.

If we release version 3.0 with new interface, we'll defenitely change this

Looking forward, Kreso

Miker