Successful problem isolation will yield earliest resolution. You (believe it or not) have more information about your environment than anyone else does, and have the greatest motivation to solve your problem. The resources at your disposal will be much more useful if the problem is specific. (Sorry if this is obvious. If it is, you might be surprised how often it's not.)
If you can demonstrate the problem with tsql or sqsh, you can expect a quick answer to your question, possibly even a fairly quick fix. (It has happened several times in the last few years that bug reports to small problems were fixed the same day. On a few occasions, new functions were added in a few days. Making FreeTDS™ useful and bugless is the goal of the project, after all.)
FreeTDS™ being what it is, problems frequently arise amidst complex environments. It can be hard for both you and the list participants — who are your allies and best resource — to determine what's going wrong. If you can submit a script that they can use to try to reproduce your results, you have a much better chance of happy resolution.
On the plus side, the list includes people with a variety of backgrounds, who frequently answer questions that aren't really about FreeTDS™ per se. Clear questions have sometimes even led to submitting patches to other projects.
FreeTDS™ comes with its own utilities that use the various libraries. It's a good idea to run your query through one of them — the one that uses the same API you're using — to see if it produces the same behavior you're seeing. That helps eliminate your application (and the rest of the calling hierarchy) as a source of the problem.