>Some more ideas:
>
>1. Could a stored procedure or something else be triggered by the INSERT into the ErrorLog table - and might there be a problem in that?
>

No stored procedures. No DBC because there's FP2x compatibility.

>2. As a guess you may be mapping a drive letter to a local folder so you can match the folder structure (or maybe even a hard-coded drive letter) at your client or their customers. There are two ways to do that:
>
>a) Set up a share, and map a drive letter to that share with NET USE or in the File Explorer GUI
>b) Use the old SUBST command in a CMD window (works fine when I've used it for this purpose)
>
>A share plus NET USE involves the networking stack (even for local shares). This can make the mapping subject to various "optimizations" such as soft disconnects. SUBST is much simpler and doesn't involve the networking stack.
>
>Whichever method you're currently using, you could try the other one instead.

Interesting. Yes, mapped. That's how the client has things set up and he walked me through it up front.

I don't remember how I set this up when I got this machine (two years ago). But I'll figure it out and try the other.


>3. Further to Christian's idea:
>- Can you confirm that what you're trying to INSERT doesn't contain anything nasty like CHR( 0 )?
>- Could there be an issue with bytes per index key exceeding 240, and/or COLLATION set to something other than MACHINE?
>- Is the column Char or VarChar?

So, found CHR(0) in the data I'm saving, but eliminating it isn't fixing the problem. I was so sure that was it.

FP2x type data so Char, not VarChar. Similarly, all that collation stuff is VFP only, I think. No index keys longer than 60 chars.

Thanks