Agree, I would first run a simple test query to confirm you see data in these tables. If running as a stored process from the stored process server, you may be authenticating to the database differently than when you run it from EG. So a simple query will show if you can see any data in the database.
When the query works from EG, are is it running on a SAS workspace server session or local PC SAS session? When the stored process runs, is it running on workspace server or stored process server?
Then I would %PUT the values of the macro vars used in the WHERE clause to look at them, to make sure they are what you want. Databases are often picky about date formats, single quotes vs second quotes, etc. What database is this?
If you are able to pull a simple query from this table, then I would do some brute force debugging with the WHERE clause. That is, start by commenting out the where clause, then uncomment pieces iteratively, to find the piece that suddenly makes the query return 0 records.
Since you're not getting any errors, I would think either you there is a prolem in your where clause, you don't have permission to see data (perhaps unlikely since you can see a table, and you're doing explicit pass-through), or something is wrong in odbc.ini file.
The Boston Area SAS Users Group (BASUG) is hosting our
in person SAS Blowout on Oct 18!
This full-day event in Cambridge, Mass features four presenters from SAS, presenting on a range of SAS 9 programming topics. Pre-registration by Oct 15 is required.
Full details and registration info at
https://www.basug.org/events.