cancel
Showing results for 
Search instead for 
Did you mean: 

Specifying Interfaces in ct_connect_string has no effect

jsberg1
Discoverer
0 Kudos

I have my interfaces file in a non-standard location. In trying to use the Python API to connect to the database, I cannot seem to specify the location of the interfaces file; specifying Interfaces in the dsn argument does not seem to have any effect. It appears that the dsn argument is passed to ct_connect_string; I have the same issue when I use ct_connect_string directly.

Here's some sample code:

  CS_CONTEXT *ctx;
  CS_CONNECTION *con;
  CS_RETCODE rc;
  
  ctx = NULL;
  rc = cs_ctx_alloc(CS_CURRENT_VERSION, &ctx);
  rc = ct_init(ctx, CS_CURRENT_VERSION);
  rc = cs_config(ctx, CS_SET, CS_MESSAGE_CB,
		 (CS_VOID *)csmsg_callback,
		 CS_UNUSED, NULL);
  rc = ct_callback(ctx, NULL, CS_SET, CS_CLIENTMSG_CB,
		   (CS_VOID *)clientmsg_callback);
  rc = ct_callback(ctx, NULL, CS_SET, CS_SERVERMSG_CB,
		   (CS_VOID *)servermsg_callback);
  /* rc = ct_config(ctx,CS_SET,CS_IFILE,IFILE,CS_NULLTERM,NULL); */
  rc = ct_con_alloc(ctx,&con);
  rc = ct_connect_string(con,
			 "Interfaces=" IFILE "; "
			 "User=UUU; "
			 "Password=PPP; "
			 "Servername=DDD",
			 CS_NULLTERM);

As written above, I get the error

Client Library error:
        severity(0) number(1) origin(8) layer(6)
        ct_connect(): directory service layer: internal directory control layer error: There was an error encountered while binding to the directory service.

But if I uncomment the ct_config line, everything works fine.

Debugging, I can see that ct_connect_string calls ct_config with CS_IFILE and the correct filename for the interfaces file. strace shows no attempt to open the specified interfaces file. So the call happens, but has no apperent effect.

So is this a bug in ct_connect_string, or am I mis-using it? My actual goal is to use the Python API, for which the only way to specify an interfaces file is to use the dsn argument, which effectively uses ct_connect_string.

sladebe
Active Participant
0 Kudos
Re: I have my interfaces file in a non-standard location
sladebe
Active Participant
0 Kudos

You said: "I have my interfaces file in a non-standard location"
Why don't you use "ct_config(ctx,CS_SET,CS_IFILE,IFILE" to run with an alternate value for IFILE?

Accepted Solutions (1)

Accepted Solutions (1)

dawn_kim
Contributor

Hi,

If you do an strace of your application it will tell what order we try to locate files.

This might be a simple double checking the environmental variables that are set.

By default in Python, you just need to set the DSQUERY variable to the location of the interfaces file.

Please reference: https://wiki.scn.sap.com/wiki/display/SYBCON/Setup+to+use+Python+module+with+sample+on+Unix

If coding in C you have to give a location in the code this links to the documentation where ifile was first introduced: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc32850.1570/html/comlib/X2...

We have a new environmental variable though introduced in SDK 15.7 SP127 and higher where you can set SYBOCS_IFILE to a defined location. You can reference it here: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc20155.1570127/doc/html/sa...

I will have documentation people include this in the new books, since it was only listed as a new feature but never carried over into the new books.

Thanks,
Dawn K.

jsberg1
Discoverer

The SYBOCS_IFILE environment variable did the trick! Thanks!

P.S. The DSQUERY environment variable didn't work; I believe it specifies the server name within the interfaces file, not the intefaces file location itself.

Answers (1)

Answers (1)

luc_vanderveurst
Participant

Hello Joseph,

With the debugging you already have done, it seems like a bug, so it would be best to report an incident.

I don't know if it would be an acceptable work-around, but you can try to specify <hosthame>:<portnumber> as servername. that works for isql, jconnect,... etc. There is no need for an interfaces file then.

Best Regards,
Luc.

jsberg1
Discoverer
0 Kudos

Thanks Luc. Unfortunately the hostname:port for does not seem to work with ct_connect_string.