FreeTDS Development Group

["James K. Lowden" <jklowden AT speakeasy.org>]

Hector,


> > In addition to the usual constraints (time, energy, enthusiasm,
> > know-how), the FreeTDS project needs an interested person who knows for 
> > instance
> > Greek or Japanese and would be willing to help with testing and such.
>
> Thank you for your comments. I would really like to help in some way. The 
> only factor is that I need i little bit of time to acquire more information 
> about both freeTDS and Japanese cosing system :)

Certainly, of course.

> I have just started using freeTDS as well as I am just starting to realize 
> all the problems a programmer must suffer when trying to put a system where 
> one of the components does not have a good documentation, or if it has, its 
> hidden somewhere.
>
> Anyway, personally I feel like its time for me to give something in return 
> to the "big community" and maybe this is a good chance.

Each person brings different talents and knowledge.  My philosophy is that 
there's always room for one more.  Not only that, but it seems there's always 
*need* for one more, especially people who know languages other than English 
and C (not that there's a surplus of English and C, either.)

> P.S. By the way, with all the problems we have decided to cope with "our" 
> problem using MS SQL's bcp command, put everything in a text file, and 
> using an automated FTP connection retrieve the files and just copy them to 
> PostgreSQL server. Until now its working fine.... maybe because until now 
> its just an idea.

The truth is, there is no good way to do what you want to do, AFAIK.  It's 
exactly your kind of story that drives people to single-vendor solutions.

You'll find the MS bcp utility gives you no error control.  It's pointless to 
put bcp.exe in any kind of script because it won't reliably set %errorlevel%. 
 Some people politely call that "broken".

In your shoes, I'd probably opt for a Perl script hosted on an NT box 
(shudder).  Perl::DBI (or even OleDb) could extract the MS-SQL data and plug 
them into PostgreSQL.  Unfortunately, that leaves you in the job-controlless 
NT environment.

In the alternative, I suppose you could use some flavor of commercial unix 
ODBC driver with Perl::DBI.  That way you'd run on a unix platform.

You see, NT is the devil I know, and the ODBC driver is the devil I don't.  I 
developed an allergy to ODBC about 10 years ago, and the only treatment is to 
stay away from it.

Regards,

--jkl