Hi Daniele, I have reproduced this. When I have the SAS_HADOOP_CONFIG_PATH= environment set properly, it works. If this isn't set properly, it creates the table but doesn't put data into it. I have the following files in there (I got them from the CDH quickstart): core-site.xml hdfs-site.xml hive-site.xml mapred-site.xml yarn-site.xml Cloudera Manager will download these for you. Connect a local browser to Cloudera Manager on the VM. This will allow you to easily get them to your PC. From the home screen select Hive. There is an Actions button in the upper right hand corner. Select Download Client Configuration from the pull-down. It will download a zip to your machine. Take the XML files and place them into the directory pointed to by your SAS_HADOOP_CONFIG_PATH= environment variable. Restart SAS so it picks up the new environment. Then run this code to see if it works. libname mycdh hadoop server=quickstart user=cloudera; data mycdh.cars;   set sashelp.cars; run; /* this is a streaming HDFS read */ proc sql;   select * from mycdh.cars; quit; /* this invokes mapreduce */ proc sql;   select count(*) from mycdh.cars; quit; ... View more

Is looks like the cluster is in standby mode. Go into Cloudera manager (under Hosts) and check-out the status. You may need to take the namenode out of standby. Have you been able to get this to work on the VM? On the VM you will need to put user=cloudera on your LIBNAME statement. That is, unless you have added a user. Can you try setting the following environment variable on the SAS machine (you will need to restart SAS)? SAS_HADOOP_RESTFUL=1 ... View more

Hi Daniele, Which version of SAS are you using? SAS 9.4M2 will tell you that there is a problem with the sticky bit. I am using the CDH 5.3 quickstart and SAS 9.4M2. The CDH Quickstart works perfectly, out of the box. I had to set the sticky bit on /tmp in order to generate the following error. /*set the sticky bit from the quickstart terminal */ sudo -u hdfs hadoop fs -chmod 1777 /tmp /* remove the sticky bit */ sudo -u hdfs hadoop fs -chmod -t /tmp Output from the SAS log. 6    libname mycdh hadoop server=quickstart port=10000; NOTE: Libref MYCDH was successfully assigned as follows:       Engine:        HADOOP       Physical Name: jdbc:hive2://quickstart:10000/default 7    data mycdh.cars2; 8       set sashelp.cars; 9    run; NOTE: SAS variable labels, formats, and lengths are not written to DBMS tables. NOTE: There were 428 observations read from the data set SASHELP.CARS. NOTE: The data set MYCDH.CARS2 has 428 observations and 15 variables. ERROR: java.sql.SQLException: Error while processing statement: FAILED: Execution Error, return        code 1 from org.apache.hadoop.hive.ql.exec.MoveTask ERROR: Unable to execute Hadoop query. ERROR: Execute error on statement: LOAD DATA INPATH        '/tmp/sasdata-2015-03-25-14-49-40-774-e-00001.dlv' OVERWRITE INTO TABLE `CARS2`. Could not        load /tmp/sasdata-2015-03-25-14-49-40-774-e-00001.dlv into table CARS2 in schema DEFAULT.        A common cause of this issue is conflicting HDFS permissions between the data file and the        Hive warehouse directory for the table.  Another possible cause is the "sticky" bit set on        HDFS directory /tmp. NOTE: DATA statement used (Total process time):       real time           0.55 seconds       cpu time            0.06 seconds If you are using an older version of SAS, say 9.4M1, you will not see this error. It will look like it works but doesn't. Previous releases of CDH quickstart had the sticky bit set. ... View more

Hi Daniele, Your problem is most likely related to the file permissions on the Hadoop /tmp directory. If SAS can't write there metadata will be created but no data loaded into the table. SAS bypasses JDBC and streams data directly into HDFS (/tmp directory). Once the data is in /tmp it is loaded into the final Hive table. This is done for performance reasons; it is very fast. Best wishes, Jeff ... View more

I am not sure that debug= will work. This is the recommended command. OPTIONS SASTRACE=',,,d' SASTRACELOC=saslog NOSTSUFFIX; ... View more

Yes ... View more

My pleasure. 1) I don't know about pricing. You may want to contact your SAS account executive. 2) You can do INSERTs on a new/empty table with both ACCESS engines. ... View more

Hi Nidhikhetrapal, SAS/ACCESS to Vertica provides a great deal of value - it is not free. Keep in mind, you must have a PRIMARY KEY defined on a vertica table in order to UPDATE and DELETE using SAS/ACCESS to Vertica. You may want to review the documentation. SAS/ACCESS(R) 9.4 for Relational Databases: Reference, Fifth Edition Here is some code... libname myvert vertica server=myvertica database=test user=myuser password=mypasswd; libname odbcvert odbc prompt; data myvert.test (dbtype=(x="integer not null, primary key(x)"));    do x = 1 to 1000;       y=x; z=x; output;    end; run; INSERT on a non-empty table test... 63   proc sql; 63 !           /* insert using ACCESS to Vertica */ 64      insert into myvert.test values (1112,1112,1112); NOTE: 1 row was inserted into MYVERT.test. 65   quit; NOTE: PROCEDURE SQL used (Total process time):       real time           0.09 seconds       cpu time            0.00 seconds 66   proc sql; 66 !           /* insert using ACCESS to ODBC */ 67      insert into odbcvert.test values (1113,1113,1113); ERROR: CLI prepare error: [Vertica][ODBC] (10280) Invalid attribute value. SQL statement: SELECT * FROM test. 68   quit; NOTE: The SAS System stopped processing this step because of errors. NOTE: PROCEDURE SQL used (Total process time):       real time           0.01 seconds       cpu time            0.00 seconds INSERT on a non-empty table works with ACCESS to Vertica and fails with ACCESS to ODBC. UPDATE Test... 99   proc sql; 99 !           /* update using ACCESS to Vertica */ 100     update myvert.test set y=2111 where x=1112; NOTE: 1 row was updated in MYVERT.test. 101  quit; NOTE: PROCEDURE SQL used (Total process time):       real time           0.11 seconds       cpu time            0.04 seconds 102  proc sql; 102!           /* update using ACCESS to ODBC */ 103     update odbcvert.test set y=9999 where x=1; ERROR: CLI prepare error: [Vertica][ODBC] (10280) Invalid attribute value. SQL statement: SELECT * FROM test. 104  quit; NOTE: The SAS System stopped processing this step because of errors. NOTE: PROCEDURE SQL used (Total process time):       real time           0.02 seconds       cpu time            0.01 seconds UPDATE works with ACCESS to Vertica and fails with ACCESS to ODBC. DELETE Test... 105  proc sql; 105!           /* update using ACCESS to Vertica */ 106     delete from myvert.test where x=1112; NOTE: 1 row was deleted from MYVERT.test. 107  quit; NOTE: PROCEDURE SQL used (Total process time):       real time           0.11 seconds       cpu time            0.01 seconds 108  proc sql; 108!           /* update using ACCESS to ODBC */ 109     delete from odbcvert.test where x=1; ERROR: CLI prepare error: [Vertica][ODBC] (10280) Invalid attribute value. SQL statement: SELECT * FROM test. 110  quit; NOTE: The SAS System stopped processing this step because of errors. NOTE: PROCEDURE SQL used (Total process time):       real time           0.01 seconds       cpu time            0.01 seconds DELETE works with ACCESS to Vertica and fails with ACCESS to ODBC. Best wishes, Jeff ... View more

Hi BStone, You are correct. SAS/ACCESS to Hadoop allows you to move data from a non-VA cluster into your VA environment. Best wishes, Jeff ... View more

Hi Sangramjit, You may want to open a different discussion for this topic. The SPDE interface is distinct from SAS/ACCESS. I notice that you say you are using Hortonworks, but you are listing Cloudera JAR files. This will lead to problems. You want to make certain that your JAR files match your distribution. Troubleshooting Kerberos issues can be fraught with peril. In order to do that someone needs to go through your XML files. If your problem is Kerberos, it is best to open a track with SAS Technical Support. Best wishes, Jeff ... View more