Toad World® Forums

sysdate@! not recognized


#1

Version 8.9 x64

There is a problem when query is running against dblink and inside code there is directive that says to use local time (not db_link one).

sysdate@!

Optimizer says Query not supported.


#2

Can you give us the SQL ?


#3

Easy. Just place that operator and some db_link which works for that user.

Unbenannt.jpeg


#4

Thank you for submitting this problem. We were not aware of this syntax before. I have added this problem into our product backlog so it will be added to future release. Your post will help improve our product.

By the way, I was trying to look up the detailed explanation about this syntax but was not able to find any. Would you be able to give me direction about where you’ve learned this syntax? Thank you for the help in advance.


#5

Hi,

No problem. Regrdless seems it is used in internal stuff…i.e.


SQL> select sysdate from dual@dblink.prod where sysdate = sysdate;
SYSDATE
-------------------
2013-07-29 12:13:57
Execution Plan
----------------------------------------------------------
Plan hash value: 4034615273
-----------------------------------------------------------------------
| Id  | Operation              | Name | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT REMOTE|      |     1 |     2   (0)| 00:00:01 |
|*  1 |  FILTER                |      |       |            |          |
|   2 |   FAST DUAL            |      |     1 |     2   (0)| 00:00:01 |
-----------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter(SYSDATE@!=SYSDATE@!)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Note
-----
   - fully remote statement

Also nice explanation is http://rwijk.blogspot.co.at/2008/07/sysdate.html

Hope this helps,
Damir


#6

Thank you for the additional information. It is very helpful.

Thanks again,

Alex