It's important to convey your setup and configuration.
| SQL Server™ version |
| FreeTDS™ version (or snapshot date, if not a release) |
| any options used with configure |
| which client library you are using |
| what language or Perl module, as appropriate, you're using |
| your client OS and hardware architecture |
If you're puzzled by some interaction with the server (often the case), it's a very good idea to set TDSDUMP and attach the log to your message. Messages are currently limited to 75 KB attachments, and the logs are quite detailed, so make your query as short as possible. If necessary, trim the log; gzip is also your friend here. It's always a good idea to post it on a website where people can fetch it if they're so inclined.
Log files are especially important if you're not programming at the C level. Sometimes there are problems — an impedance mismatch, to coin a phrase — between FreeTDS™ and the calling framework/language. But if you write to the list and say “Why does my PHP foo() returns an empty string?”, please keep in mind that your question might as well be in Urdu to someone familiar with the C library. Without knowing which C function was called, and with what data, it's impossible to even begin to try to answer the question.
Think about it this way: If you attach a log no one reads, you wasted some bandwidth. If you don't attach one and someone asks you for it, you wasted a day. Like that.
Great questions make the problem crystal clear to a tired developer after supper.
Show what you did, and show what happened. Throughout this User Guide, you've seen examples of screenshots; in each case the first line was the command entered, followed by the machine's response. By showing verbatim what you did and saw, you give someone who knows what to do a chance to look over your shoulder. Across the Internet! How cool is that?
Whether you're having a problem with your own application or with something at a higher level, you're well advised to try to reproduce it using one of the FreeTDS™ utilities, preferably one that used the same client library you're using. If, say, bsqldb works and your program doesn't, that's a clue. By the same token, if bsqldb exhibits problems, too, chances are you found a bug. Or — how to say it? — a missing feature. It's always good to know about those.