BookmarkSubscribeRSS Feed
ScottBass
Rhodochrosite | Level 12

Hi,

 

I'm having a disagreement with my local SAS Tech Support, but I'm happy to be convinced that I'm incorrect.

 

I'm accessing SQL Server tables via the ODBC engine.  The two relevant tables are named RLDX_AUDIT_TRAIL and Record.  The capitalization is important.

 

Here is some test code:

 

* set desired SAS options ;
options sastrace=',,,d' sastraceloc=saslog nostsuffix;
options msglevel=I;
options fullstimer;
options mprint mrecall;
options compress=binary;
options ls=max;
options nocenter;
options lognumberformat=1;

libname sqlsvr odbc 
   NOPROMPT="Driver={SQL Server Native Client 10.0};Server=MYSERVER;Database=MYDB_dev;Trusted_Connection=yes;"
   bulkload=yes 
   schema=rldxhosp
   preserve_tab_names=no
;

filename temp temp;

* Note: RLDX_AUDIT_TRAIL has 29 records, Record exists but is an empty table (0 records) ;
proc datasets lib=sqlsvr;
   copy out=work;
   select rldx_audit_trail record;
quit;
proc datasets lib=sqlsvr;
   copy out=work;
   select RLDX_AUDIT_TRAIL record;
quit;
proc datasets lib=sqlsvr;
   copy out=work;
   select RLDX_AUDIT_TRAIL Record;
quit;

proc copy in=sqlsvr out=work;
   select rldx_audit_trail record;
quit;
proc copy in=sqlsvr out=work;
   select RLDX_AUDIT_TRAIL record;
quit;
proc copy in=sqlsvr out=work;
   select RLDX_AUDIT_TRAIL Record;
quit;

proc cport lib=sqlsvr file="%sysfunc(pathname(temp))";
   select rldx_audit_trail record;
run;
proc cport lib=sqlsvr file="%sysfunc(pathname(temp))";
   select RLDX_AUDIT_TRAIL record;
run;
proc cport lib=sqlsvr file="%sysfunc(pathname(temp))";
   select RLDX_AUDIT_TRAIL Record;
run;

And here is the log:

 

1 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

1          ;*';*";*/;quit;run;
2          OPTIONS LS=120 PS=50;
3          OPTIONS PAGENO=MIN;
4          %LET _CLIENTTASKLABEL='preserve_tab_names=NO';
6          %LET _CLIENTPROJECTNAME='SAS ODBC case sensititivy.egp';
7          %LET _SASPROGRAMFILE=;
8          
9          ODS _ALL_ CLOSE;
10         OPTIONS DEV=ACTIVEX;
11         GOPTIONS XPIXELS=0 YPIXELS=0;
12         FILENAME EGSR TEMP;
13         ODS tagsets.sasreport13(ID=EGSR) FILE=EGSR
14             STYLE=HtmlBlue
15             STYLESHEET=(URL="file:///C:/Program%20Files%20(x86)/SASHome/x86/SASEnterpriseGuide/6.1/Styles/HtmlBlue.cs
15       ! s")
16             NOGTITLE
17             NOGFOOTNOTE
18             GPATH=&sasworklocation
19             ENCODING=UTF8
20             options(rolap="on")
21         ;
NOTE: Writing TAGSETS.SASREPORT13(EGSR) Body file: EGSR
22         
23         GOPTIONS ACCESSIBLE;
24         * set desired SAS options ;
25         options sastrace=',,,d' sastraceloc=saslog nostsuffix;
26         options msglevel=I;
27         options fullstimer;
28         options mprint mrecall;
29         options compress=binary;
30         options ls=max;
31         options nocenter;
32         options lognumberformat=1;
33         
34         libname sqlsvr odbc
ODBC: AUTOCOMMIT is NO for connection 0
35            NOPROMPT=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
36            bulkload=yes
37            schema=rldxhosp
38            preserve_tab_names=no
39         ;
NOTE: Libref SQLSVR was successfully assigned as follows: 
      Engine:        ODBC 
      Physical Name: 
40         
41         filename temp temp;
2 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

42         
43         * Note: RLDX_AUDIT_TRAIL has 29 records, Record exists but is an empty table (0 records) ;
44         proc datasets lib=sqlsvr;
ODBC: AUTOCOMMIT is NO for connection 1
ODBC: Called SQLTables with schema of rldxhosp
45            copy out=work;
46            select rldx_audit_trail record;
47         quit;

ERROR: The file SQLSVR.rldx_audit_trail (memtype=ALL) was not found, but appears on a SELECT statement.
ERROR: The file SQLSVR.record (memtype=ALL) was not found, but appears on a SELECT statement.
NOTE: Statements not processed because of errors noted above.
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE DATASETS used (Total process time):
      real time           0.15 seconds
      user cpu time       0.03 seconds
      system cpu time     0.00 seconds
      memory              639.90k
      OS Memory           14116.00k
      Timestamp           04/12/2017 11:55:14 AM
      


48         proc datasets lib=sqlsvr;
ODBC: Called SQLTables with schema of rldxhosp
49            copy out=work;
50            select RLDX_AUDIT_TRAIL record;
51         quit;

NOTE: Copying SQLSVR.RLDX_AUDIT_TRAIL to WORK.RLDX_AUDIT_TRAIL (memtype=DATA).
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_1: Prepared: on connection 2
SELECT * FROM rldxhosp.RLDX_AUDIT_TRAIL
 
NOTE: BUFSIZE is not cloned when copying across different engines. System Option for BUFSIZE was used.
INFO: Data set block I/O cannot be used because:
INFO:   -  The data sets use different engines, have different variables or have attributes that may differ.
 
ODBC_2: Executed: on connection 2
Prepared statement ODBC_1
 
NOTE: There were 29 observations read from the data set SQLSVR.RLDX_AUDIT_TRAIL.
NOTE: The data set WORK.RLDX_AUDIT_TRAIL has 29 observations and 21 variables.
NOTE: Compressing data set WORK.RLDX_AUDIT_TRAIL increased size by 100.00 percent. 
      Compressed is 2 pages; un-compressed would require 1 pages.
ERROR: The file SQLSVR.record (memtype=ALL) was not found, but appears on a SELECT statement.
NOTE: Statements not processed because of errors noted above.
3 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE DATASETS used (Total process time):
      real time           0.10 seconds
      user cpu time       0.01 seconds
      system cpu time     0.01 seconds
      memory              394.40k
      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      


52         proc datasets lib=sqlsvr;
ODBC: Called SQLTables with schema of rldxhosp
53            copy out=work;
54            select RLDX_AUDIT_TRAIL Record;
55         quit;

NOTE: Copying SQLSVR.RLDX_AUDIT_TRAIL to WORK.RLDX_AUDIT_TRAIL (memtype=DATA).
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_3: Prepared: on connection 2
SELECT * FROM rldxhosp.RLDX_AUDIT_TRAIL
 
NOTE: BUFSIZE is not cloned when copying across different engines. System Option for BUFSIZE was used.
INFO: Data set block I/O cannot be used because:
INFO:   -  The data sets use different engines, have different variables or have attributes that may differ.
 
ODBC_4: Executed: on connection 2
Prepared statement ODBC_3
 
NOTE: There were 29 observations read from the data set SQLSVR.RLDX_AUDIT_TRAIL.
NOTE: The data set WORK.RLDX_AUDIT_TRAIL has 29 observations and 21 variables.
NOTE: Compressing data set WORK.RLDX_AUDIT_TRAIL increased size by 100.00 percent. 
      Compressed is 2 pages; un-compressed would require 1 pages.
NOTE: Copying SQLSVR.Record to WORK.RECORD (memtype=DATA).
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_5: Prepared: on connection 2
SELECT * FROM rldxhosp.Record
 
NOTE: BUFSIZE is not cloned when copying across different engines. System Option for BUFSIZE was used.
INFO: Data set block I/O cannot be used because:
INFO:   -  The data sets use different engines, have different variables or have attributes that may differ.
 
ODBC_6: Executed: on connection 2
Prepared statement ODBC_5
 
NOTE: There were 0 observations read from the data set SQLSVR.Record.
4 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

NOTE: The data set WORK.RECORD has 0 observations and 9 variables.
NOTE: PROCEDURE DATASETS used (Total process time):
      real time           0.15 seconds
      user cpu time       0.01 seconds
      system cpu time     0.01 seconds
      memory              417.15k
      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      

56         
57         proc copy in=sqlsvr out=work;
58            select rldx_audit_trail record;
59         quit;

ODBC: Called SQLTables with schema of rldxhosp
ERROR: The file SQLSVR.rldx_audit_trail (memtype=ALL) was not found, but appears on a SELECT statement.
ERROR: The file SQLSVR.record (memtype=ALL) was not found, but appears on a SELECT statement.
NOTE: Statements not processed because of errors noted above.
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE COPY used (Total process time):
      real time           0.01 seconds
      user cpu time       0.00 seconds
      system cpu time     0.00 seconds
      memory              91.37k
      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      


60         proc copy in=sqlsvr out=work;
61            select RLDX_AUDIT_TRAIL record;
62         quit;

ODBC: Called SQLTables with schema of rldxhosp
NOTE: Copying SQLSVR.RLDX_AUDIT_TRAIL to WORK.RLDX_AUDIT_TRAIL (memtype=DATA).
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_7: Prepared: on connection 2
SELECT * FROM rldxhosp.RLDX_AUDIT_TRAIL
 
NOTE: BUFSIZE is not cloned when copying across different engines. System Option for BUFSIZE was used.
INFO: Data set block I/O cannot be used because:
INFO:   -  The data sets use different engines, have different variables or have attributes that may differ.
 
ODBC_8: Executed: on connection 2
Prepared statement ODBC_7
 
5 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

NOTE: There were 29 observations read from the data set SQLSVR.RLDX_AUDIT_TRAIL.
NOTE: The data set WORK.RLDX_AUDIT_TRAIL has 29 observations and 21 variables.
NOTE: Compressing data set WORK.RLDX_AUDIT_TRAIL increased size by 100.00 percent. 
      Compressed is 2 pages; un-compressed would require 1 pages.
ERROR: The file SQLSVR.record (memtype=ALL) was not found, but appears on a SELECT statement.
NOTE: Statements not processed because of errors noted above.
NOTE: The SAS System stopped processing this step because of errors.
NOTE: PROCEDURE COPY used (Total process time):
      real time           0.06 seconds
      user cpu time       0.00 seconds
      system cpu time     0.01 seconds
      memory              297.43k
      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      


63         proc copy in=sqlsvr out=work;
64            select RLDX_AUDIT_TRAIL Record;
65         quit;

ODBC: Called SQLTables with schema of rldxhosp
NOTE: Copying SQLSVR.RLDX_AUDIT_TRAIL to WORK.RLDX_AUDIT_TRAIL (memtype=DATA).
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_9: Prepared: on connection 2
SELECT * FROM rldxhosp.RLDX_AUDIT_TRAIL
 
NOTE: BUFSIZE is not cloned when copying across different engines. System Option for BUFSIZE was used.
INFO: Data set block I/O cannot be used because:
INFO:   -  The data sets use different engines, have different variables or have attributes that may differ.
 
ODBC_10: Executed: on connection 2
Prepared statement ODBC_9
 
NOTE: There were 29 observations read from the data set SQLSVR.RLDX_AUDIT_TRAIL.
NOTE: The data set WORK.RLDX_AUDIT_TRAIL has 29 observations and 21 variables.
NOTE: Compressing data set WORK.RLDX_AUDIT_TRAIL increased size by 100.00 percent. 
      Compressed is 2 pages; un-compressed would require 1 pages.
NOTE: Copying SQLSVR.Record to WORK.RECORD (memtype=DATA).
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_11: Prepared: on connection 2
SELECT * FROM rldxhosp.Record
 
NOTE: BUFSIZE is not cloned when copying across different engines. System Option for BUFSIZE was used.
INFO: Data set block I/O cannot be used because:
INFO:   -  The data sets use different engines, have different variables or have attributes that may differ.
6 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

 
ODBC_12: Executed: on connection 2
Prepared statement ODBC_11
 
NOTE: There were 0 observations read from the data set SQLSVR.Record.
NOTE: The data set WORK.RECORD has 0 observations and 9 variables.
NOTE: PROCEDURE COPY used (Total process time):
      real time           0.12 seconds
      user cpu time       0.01 seconds
      system cpu time     0.00 seconds
      memory              321.71k
      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      

66         
67         proc cport lib=sqlsvr file="%sysfunc(pathname(temp))";
68            select rldx_audit_trail record;
69         run;

ODBC: Called SQLTables with schema of rldxhosp
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_13: Prepared: on connection 2
SELECT * FROM rldxhosp.RLDX_AUDIT_TRAIL
 

NOTE: PROC CPORT begins to transport data set SQLSVR.RLDX_AUDIT_TRAIL
 
ODBC_14: Executed: on connection 2
Prepared statement ODBC_13
 
NOTE: The data set contains 21 variables and 29 observations. 
      Logical record length is 485.
WARNING: Specified member SQLSVR.RECORD.* was not found.
NOTE: PROCEDURE CPORT used (Total process time):
      real time           0.10 seconds
      user cpu time       0.01 seconds
      system cpu time     0.00 seconds
      memory              135.62k
      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      

70         proc cport lib=sqlsvr file="%sysfunc(pathname(temp))";
71            select RLDX_AUDIT_TRAIL record;
72         run;

7 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

ODBC: Called SQLTables with schema of rldxhosp
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_15: Prepared: on connection 2
SELECT * FROM rldxhosp.RLDX_AUDIT_TRAIL
 

NOTE: PROC CPORT begins to transport data set SQLSVR.RLDX_AUDIT_TRAIL
 
ODBC_16: Executed: on connection 2
Prepared statement ODBC_15
 
NOTE: The data set contains 21 variables and 29 observations. 
      Logical record length is 485.
WARNING: Specified member SQLSVR.RECORD.* was not found.
NOTE: PROCEDURE CPORT used (Total process time):
      real time           0.10 seconds
      user cpu time       0.01 seconds
      system cpu time     0.00 seconds
      memory              135.62k
      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      

73         proc cport lib=sqlsvr file="%sysfunc(pathname(temp))";
74            select RLDX_AUDIT_TRAIL Record;
75         run;

ODBC: Called SQLTables with schema of rldxhosp
ODBC: AUTOCOMMIT is NO for connection 2
 
ODBC_17: Prepared: on connection 2
SELECT * FROM rldxhosp.RLDX_AUDIT_TRAIL
 

NOTE: PROC CPORT begins to transport data set SQLSVR.RLDX_AUDIT_TRAIL
 
ODBC_18: Executed: on connection 2
Prepared statement ODBC_17
 
NOTE: The data set contains 21 variables and 29 observations. 
      Logical record length is 485.
WARNING: Specified member SQLSVR.RECORD.* was not found.
NOTE: PROCEDURE CPORT used (Total process time):
      real time           0.07 seconds
      user cpu time       0.01 seconds
      system cpu time     0.00 seconds
      memory              135.62k
8 The SAS System                                                                                                                                                                                                                 11:27 Wednesday, April 12, 2017

      OS Memory           14372.00k
      Timestamp           04/12/2017 11:55:14 AM
      

76         
77         
78         GOPTIONS NOACCESSIBLE;
79         %LET _CLIENTTASKLABEL=;
80         %LET _CLIENTPROJECTPATH=;
81         %LET _CLIENTPROJECTNAME=;
82         %LET _SASPROGRAMFILE=;
83         
84         ;*';*";*/;quit;run;
85         ODS _ALL_ CLOSE;
86         
87         
88         QUIT; RUN;
89         

I get the same results whether preserve_tab_names=yes or no.

 

Questions:

 

1) For PROC DATASETS and PROC COPY, should the select statement be case-sensitive for the table names?  From the sastrace output, I see:

 

ODBC: AUTOCOMMIT is NO for connection 1
ODBC: Called SQLTables with schema of rldxhosp

 

I'm thinking that "Called SQLTables" isn't doing the right thing, and SAS thinks the tables don't exist, when they do.

 

2) For PROC CPORT, should the select statement behave consistently with the select statement for PROC DATASETS and PROC COPY?  Because it isn't - it appears to be uppercasing the table names, and then not finding the table.  I can export the RLDX_AUDIT_TRAIL table because its name is already all uppercase, but I can't export the Record table at all.

 

3) Here is the doc link for CPORT:  

http://support.sas.com/documentation/cdl/en/proc/70377/HTML/default/viewer.htm#n1c1z2uzw5ejpfn1cp87c...

 

It says it supports SAS datasets, SAS catalogs, etc.  IMO, a SAS/Access table is a "virtual SAS dataset", in that I can (usually) use it where I would use a SAS dataset (set statement, from statement, etc).  So, should I expect to be able to directly export a SQL Server without creating an intermediate SAS dataset (just so PROC CPORT will work)?

 

Lastly, it's interesting that my SQL Server database is not case sensitive.  See attached screenshot.

 

Thanks!


2017-04-13_15-32-43.png

Please post your question as a self-contained data step in the form of "have" (source) and "want" (desired results).
I won't contribute to your post if I can't cut-and-paste your syntactically correct code into SAS.
6 REPLIES 6
RW9
Diamond | Level 26 RW9
Diamond | Level 26

Too long a post.  To try to answer your questions:

1)  Well, within SAS casing should not matter.  It is only when you are passing through to the database that casing matters.  What you have here is a blurring of where things happen in SAS and where things happen in the database.  My suggestion, have one block at the top which gets the data from the database and saves it to a SAS dataset so there is a clear delineation between the two.  After that casing should not matter.

2)  As above, get that clear deliniation between DB and SAS, in your code you keep going back to the database for each step, do the download once, then the rest of it in SAS.

3)  It may appear to you as a "virtual dataset", but it is not.  Behind the scenes there is a lot more happening, and the table is more of a pipe.  Again, as above, clear dilneation will resolve all this. 

So:

/* This block gets data from database */

 

/* Close database connection */

 

/* Continue processing in SAS */

 

ScottBass
Rhodochrosite | Level 12

Sorry for the length of the post - I'm open to ideas as to how I could have conveyed the issue more succinctly.

 

I don't want to download millions of records from SQL Server to SAS just to have a "clear deliniation between DB and SAS", so that I then get case insensitivity.

 

I also want the SELECT statement to work as expected (or at least as I expect it - I admit "expected" is subject to debate).

 

From what I can see, with a DB, SAS will pass through code to the DB to determine if the table exists.  I assert that that "under the covers" code is buggy, in that it's making the comparison as case sensitive, and determining that the table does not exist, when it does.

 

In the case of PROC CPORT, it appears that it is inconsistent with DATASETS and COPY by uppercasing the returned list of tables.  As a result, I can't use a select statement with PROC CPORT unless I uppercase my tables in SQL Server.  It is impossible for me to CPORT a mixed case DB table without first downloading it to SAS.  IMO I shouldn't have to do this.

 

Ultimately, I want to use DATASETS, COPY, CPORT (and others?) with a SELECT statement, using case insensitive names, and do my processing in the most efficient manner.  

 

Your approach:

 

/* This block gets data from database */

 

/* Close database connection */

 

/* Continue processing in SAS */

 

does not do this.  


Please post your question as a self-contained data step in the form of "have" (source) and "want" (desired results).
I won't contribute to your post if I can't cut-and-paste your syntactically correct code into SAS.
RW9
Diamond | Level 26 RW9
Diamond | Level 26

Open a ticket with SAS IT support for them to work through it with you.

Tom
Super User Tom
Super User

It sounds like the foreign database has case sensitive table names?  So the table ABC is different than the table Abc.  

Is it like Unix filesystem and you can have both tables at the same time?  Or is it like DOS it remembers the case you used but restricts you from making another name that would be the same if case was consistent?

 

Is the problem that you are not finding the table? Or that the table's mixed case name is getting destroyed when copied to a dataset in SAS? I know some people really like their caMeL case names, but if it is just a cosmetic issue like that it is a different level of problem.

 

Can you make a little summary of what the issue is and how the different proc's you tested are impacted?  At least then even if SAS makes no changes we know for which procs we need to worry about the case of table names and can perhaps create some work arounds.

 

For example PROC CPORT is more for exporting data and so perhaps requiring an extra step (such as creating a view and exporting from the view) might be a reasonable work around.  But if you are trying to use PROC SUMMARY and expecting SAS to be able to push the processing into the database then issues with finding the tables would be a bigger problem and view might not work if it forces PROC SUMMARY to pull all of the data to SAS before processing.

ScottBass
Rhodochrosite | Level 12

@Tom wrote:

It sounds like the foreign database has case sensitive table names?  So the table ABC is different than the table Abc.

 

SB:  No the foreign database is SQL Server and the database is not case sensitive.  If I enter:

 

select * from tablename, select * from TableName, or select * from TABLENAME

 

in the Sql Server Management Studio client, they all "work".  I also posted output from SSMS where even a query against the system tables was case insensitive.

 

Is it like Unix filesystem and you can have both tables at the same time?  Or is it like DOS it remembers the case you used but restricts you from making another name that would be the same if case was consistent?

 

SB:  It's Sql Server on Windows.  I cannot create TABLENAME if tablename already exists.

 

Is the problem that you are not finding the table?

 

SB:  No, the problem is that ***SAS*** is not finding the table.  From the sastrace output, I believe SAS is doing passthrough "under the covers" when the SELECT statement is used, is doing this in a case sensitive manner, and determines that the table doesn't exist when it does.  Please review the (admittedly long) SAS log to see what I mean.

 

Or that the table's mixed case name is getting destroyed when copied to a dataset in SAS?

 

SB:  No, I'm not copying the data to a SAS dataset.  The issue is in the SELECT statement, and the code that SAS is using under the covers to check if the table exists.

 

I know some people really like their caMeL case names, but if it is just a cosmetic issue like that it is a different level of problem.

 

Can you make a little summary of what the issue is and how the different proc's you tested are impacted?  

 

SB:  I thought that's what I did in my OP?  In any case, see comments above.

 

At least then even if SAS makes no changes we know for which procs we need to worry about the case of table names and can perhaps create some work arounds.

 

For example PROC CPORT is more for exporting data and so perhaps requiring an extra step (such as creating a view and exporting from the view) might be a reasonable work around.  

 

SB:  For CPORT, I'm trying to use a SELECT statement against the ODBC library definition to select only the tables of interest and create a transport file without having to create an intermediate SAS dataset.  But the current functionality prevents this.  IMO it's a design bug, but perhaps I'm wrong in that opinion?

 

But if you are trying to use PROC SUMMARY and expecting SAS to be able to push the processing into the database then issues with finding the tables would be a bigger problem and view might not work if it forces PROC SUMMARY to pull all of the data to SAS before processing.


 


Please post your question as a self-contained data step in the form of "have" (source) and "want" (desired results).
I won't contribute to your post if I can't cut-and-paste your syntactically correct code into SAS.
Tom
Super User Tom
Super User

So if the issue is should PROC COPY and PROC DATASETS (or any other proc that allows lists of memnames) find members in ODBC or other external databases then the I am all for saying this is a SAS bug that they need to fix.

 

Not knowing anything about how the internals of these PROCs or ODBC work I am not sure how hard it will be for them to fix.

sas-innovate-2024.png

Join us for SAS Innovate April 16-19 at the Aria in Las Vegas. Bring the team and save big with our group pricing for a limited time only.

Pre-conference courses and tutorials are filling up fast and are always a sellout. Register today to reserve your seat.

 

Register now!

How to connect to databases in SAS Viya

Need to connect to databases in SAS Viya? SAS’ David Ghan shows you two methods – via SAS/ACCESS LIBNAME and SAS Data Connector SASLIBS – in this video.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 6 replies
  • 3331 views
  • 0 likes
  • 3 in conversation