If the task is one that I created, then I will say "it's safe."  Many of the tasks I built early on and distributed are now part of the main application anyway.   In general, it's a good idea to find out from the task creator exactly what the task is going to do.  Assuming it's a .NET assembly (it must be), it is possible to disassemble the DLL using standard tools and review it thoroughly.  But...that's overkill if you can trust the source.   When downloading a task from the internet, this additional step is almost always necessary to install. ... View more

Using Proc FedSQL you can do what you need. The IPTRACE option will show the SQL pushed down to the DBMS, code example courtesy to @SASJedi   proc fedsql iptrace; drop table fedsql_2_24 force; create table fedsql_2_24 as select * from xora.xtimetest where tsb > tsa + ( 2 / 24 ) ; quit; However since your users are using SAS Enterprise Guide query window, I think you need to write two functions: One using Proc FCMP, so SAS will understand it One in Oracle doing the date math   Then add the function information to the LIBNAME statement, so that the function is recognized for push down. See this entry for more details: https://communities.sas.com/t5/Base-SAS-Programming/Using-a-Teradata-UDF-in-SAS-Implicit-Sql-Pass-Thru/m-p/266454/highlight/true#M52527   ... View more

Why?  Because you are using two different methods. If you ask it to use SAS/Access then it will use PROC IMPORT to read the file. Otherwise Enterprise Guide will convert the Excel file to a text file, copy the text file to your SAS server and write a data step to read it.   If you are always going to use Enterprise Guide and the source file is available to use on the machine where Enterprise Guide is running then I would recommend using that tool as I think you will have better control over the result.   Using PROC IMPORT to convert a file requires it to guess at what the file contains. ... View more