FreeTDS Development Group

["Coleman, Dave" <DColeman AT US.TIAuto.com>]

Our application uses an object which allocates theses structures and saves
them, simply connect()ing and close()ing the socket.  This reduces the
number of gethostbyname() calls to one per object, as each object is
dedicated to the server it is instantiated with, making for a very
lite/reusable non-persistant connection class.  (I have not tested
portability, but it has survived a number of RedHat releases, in addition to
more than a few freetds releases even though the structures keep changing on
me.)  :-)

I was curious if the following should work?

TDSSOCKET* tdsDB::openDB(TDSLOGIN *login)
   {
   TDSSOCKET   *tds = NULL;
   static struct sockaddr_in      sin;
   int addrLen;

   if ( !connected )
      {
      if ( !initialized )
         {
         //LOG((12,"creating context\n"));
         context = tds_alloc_context();
        
/*
it seems to me from reading the code that if there is no locale section
read, the locale* will be NULL...

can I then do:
*/      
        if( !context->locale ) {
                tds_alloc_locale(context->locale);
                }

         //LOG((12,"creating socket\n"));
         tds = tds_alloc_socket(context, 512);
         //LOG((12,"creating config\n"));
         config = tds_get_config(tds, login, context->locale);
         tds_set_parent(tds, this);
         tds->tds_ctx->err_handler = tdsdb_raise_error;
         tds->tds_ctx->msg_handler = tdsdb_handle_message;
         tds->major_version=config->major_version;
         tds->minor_version=config->minor_version;
         tds->emul_little_endian=config->emul_little_endian;
         /* Jeff's hack - begin */
         tds->timeout = 20;
         tds->longquery_timeout = (login->connect_timeout) ?
login->longquery_timeout : 0;
         tds->longquery_func = login->longquery_func;
         tds->longquery_param = login->longquery_param;
         /* end */
         memcpy(tds->capabilities,login->capabilities,TDS_MAX_CAPABILITY);
         //LOG((12,"connection initialized\n"));
         if ( config->ip_addr )
            {
            initialized = 1;
            }
         }
      else
         {
         //LOG((12,"re-using socket\n"));
         tds = sqlSock;
         tds_reset_msg_info(tds->msg_info);
         tds_free_all_results(tds);
         }
        //***************************************************************
        //      proposed language trick....
        char lang_buf[2];
        char char_set_buf[2];
        // for now let's say that *lang_buf == {"en"},
        //              that *char_set_buf == {"US"},
        //      and that these will be set externally via a means that will
maintain ISO standards on the values.
        config->language = context->locale->language = strdup(lang_buf);
        config->char_set = context->locale->char_set = strdup(char_set_buf);
        context->locale->date_fmt = strdup(date_fmt_buf);
        //***************************************************************
It would seem that this should allow me to change the value each time before

I call tds_send_login and tds_process login, or have I missed something?

If this does allow me to change the values used for logging in to the
server, how do I ask the server (which will be by default, in one language)
to pass me messages in another language?  I.E. if the server is en_US, can I
change the language value to sp, making the login ask for sp_US and get
spanish error messages?
        //***************************************************************
      //LOG((12,"getting network configuration\n"));
      if ( config->ip_addr )
         {
         sin.sin_addr.s_addr = inet_addr(config->ip_addr);
         addrLen = sizeof(sin);
         sin.sin_family = AF_INET;
         sin.sin_port = htons(config->port);
         //LOG((12,"binding socket\n"));
         tds->s = socket (AF_INET, SOCK_STREAM, 0);
         }
      else
         {
         // ERROR : could not resolve IP address of server
         perror("tdsdb::openDB()");
         tds->s = -2;
         }
      if ( tds->s < 0 )
         {
         //LOG((0,"ERROR while binding socket\n"));
         perror ("socket");
         if ( !initialized )
            {
            //LOG((0,"freeing tds_context\n"));
            if ( tds->tds_ctx )
               {
               tds_free_context(tds->tds_ctx);
               }
            //LOG((0,"freeing config\n"));
            tds_free_config(config);
            //LOG((0,"freeing socket\n"));
            tds_free_socket(tds);
            }
         return NULL;
         }
      LOG((12,"looking for [%s]\n",server));
      if ( connect(tds->s, (struct sockaddr *) &sin, sizeof(sin)) < 0 )
         {
         LOG((0,"ERROR finding [%s]\n",server));
         close(tds->s);
         perror("connect");
         if ( !initialized )
            {
            //LOG((0,"freeing tds_context\n"));
            if ( tds->tds_ctx )
               {
               tds_free_context(tds->tds_ctx);
               }
            //LOG((0,"freeing config\n"));
            tds_free_config(config);
            //LOG((0,"freeing socket\n"));
            tds_free_socket(tds);
            }
         return NULL;
         }

      tds->out_flag=0x02;
      LOG((12,"logging in to SQL Service on
[%s]:%d...\n",server,config->port));
      tds_send_login(tds,config);

      //LOG((12,"processing login\n"));
      if ( !tds_process_login_tokens(tds) )
         {
         LOG((0,"ERROR : tds_process_login_tokens failed\n"));
         if ( !initialized )
            {
            if ( tds->tds_ctx )
               {
               //LOG((0,"freeing tds_context\n"));
               tds_free_context(tds->tds_ctx);
               }
            //LOG((0,"freeing config\n"));
            tds_free_config(config);
            //LOG((0,"freeing socket\n"));
            tds_free_socket(tds);
            tds = NULL;
            }
         offLine = 1;
         }
      else
         {
         LOG((12,"logged in\n"));
         }
      }
   if ( tds )
      {
      loggedIn = 1;
      offLine = 0;
      connected = 1;
      //LOG((12,"done connecting to [%s]\n",server));
      }
   else
      {
      LOG((0,"ERROR connecting to [%s]\n",server));
      }
   return tds;
   }

> -----Original Message-----
> From: James K. Lowden [SMTP:jklowden AT schemamania.org]
> Sent: Saturday, January 11, 2003 6:28 PM
> To:   TDS Development Group
> Subject:      Re: [freetds] How to set locales.conf in spanish
> 
> On Fri, 10 Jan 2003 21:57:47 -0500, "Coleman, Dave"
> <DColeman AT US.TIAuto.com> wrote:
> > Is it possible to set these at run time?
> > 
> > I would like to be able to set 'en_MX', 'en_US' and 'sp_MX' after the
> > creation of the TDS_SOCKET*/LOGIN*/LOCALE* bundle.  Theoretically I
> > should be able to set those values before I tds_send_login(...), right?
> 
> If you mean the environment strings, from what I've read, you need to set
> those values before your application starts up, if you want portable code.
>  Different libc implementations react differently (or not at all) to
> changes in the environment once the application starts.  I think I read
> about that in perl's documentation.  
> 
> If you mean calling setlocale(3), yes, that has to happen before
> tds_send_login().  Not that we pay any attention atm, whatever you do.  
> 
> In any case, I'm not you can affect very much after connecting. 
> dbsetlnatlang() for example has to be called before dbopen().  
> 
> I intend to split off reading the configuration information from the login
> function, by the way.  It's messy as it is, if I may say so.  You can't
> query the library for, say, available servers (dbserverenum() for
> Microsoft), nor can you find out, say, what TDS version will be used to
> connect to a server without trying it and looking at the log.  I've
> written a standalone library, libnvp, that reads any freetds.conf-like
> file and stores it in memory.  The application can then query it by key. 
> I haven't incorporated it yet or released it separately because it lacks
> documentation, because I haven't installed doxygen, because I want to
> upgrade my OS and release 0.61 first....  Sigh.  
> 
> --jkl
> 
> > -----Original Message-----
> > From: James K. Lowden
> > To: freetds AT lists.ibiblio.org
> > Sent: 1/10/03 11:36 AM
> > Subject: Re: [freetds] How to set locales.conf in spanish
> > 
> > On Thu, 9 Jan 2003 21:42:09 -0800 (PST), Aliet Santiesteban Sifontes
> > <alietss AT yahoo.com> wrote:
> > > I'm trying to configure my
> > > locales.conf to be spanish rather english, so I can
> > > use the spanish language, anybody could tell me what
> > > do I have to do??
> > 
> > Aliet, 
> > 
> > Thank you for asking that question.  I've been meaning to redo that page
> > in the User Guide, and, as a matter of fact, I think we need to redo
> > some
> > of the code, too.  
> > 
> > locales.conf is not intended to be customized; it is a read-only data
> > file
> > associating national conventions with server settings.  It is incomplete
> > (in fact it's barely begun), and additions are welcome.  
> > 
> > FreeTDS reads the LANG environment variable, and uses it as a key into
> > locales.conf.  It expects a 5-character value in $LANG: 2 (lowercase)
> > for
> > the language, an underscore, and 2 (uppercase) for the country.  The
> > domain of values for language and country is governed by ISO standards.
> > 
> > 
> > Language codes (ISO 639:1988, now 639-1) are online at
> > http://www.loc.gov/standards/iso639-2/langhome.html
> > 
> > Country codes (ISO 3166) are online at
> > http://www.din.de/gremien/nas/nabd/iso3166ma/codlstp1/en_listp1.html
> > 
> > For Spanish in Spain, LANG=es_ES.  
> > 
> > FreeTDS inspects locales.conf for a section matching $LANG, looking for
> > settings for the date format, language, and character set.  
> > 
> > The date format string, as the UG says, is used by strftime(3).  Set it
> > in
> > accordance with your country's standard representation.  (Your personal
> > preference, if different, would be reflected in freetds.conf, which will
> > override the locales.conf setting.)  
> > 
> > The language, and character set are sent to the server; their domains
> > are
> > defined by the vendors.  
> > 
> > The language value is sent to the server at login time.  It determines
> > what language your messages will be in.  It does not affect collation.  
> > 
> > The character set is sent to Sybase servers (and to Microsoft servers,
> > if
> > using TDS 4.2).  It determines what character set your data will be
> > encoded with when sent to the client.  
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds