That argument is there to tell the *client* not to use the cached request, so it will make a fresh one. It's okay for the server to ignore the cache busting argument, as long as it responds with data.

If there is something else going on, please reopen with more details about what the client sends and how the server responds. A trace with Fiddler or Wireshark might help.

I came across this as well. I know you request a test case, but simply the $.ajax() function works as expected in generating the URL, but the '_=' in the query string is invalid syntax for PL/SQL. All PL/SQL identifiers must begin with a letter. The *client* in this instance doesn't ignore it.

OUTPUT URL:

http://[hostname]/[dadname]/ajax_script.prc?_=2323876868688&p_id=1

ERROR:

400 Bad Request => "Bad name in request: not a legal PLSQL identifier..."

@shantydweller, only way around it currently is to manually add a "p_nocache=TIMESTAMP" to query string, as well as, add it to the requested stored procedure's IN parameters as well. Tedious, but it works.

This can be fixed with flexible paramter passing:

procedure ck(name_array owa.vc_arr, value_array owa.vc_arr) is

begin

htp.p('test '||to_char(sysdate, 'hh:mi:ss'));

end;

<script>

$.ajax({

url: '!ck',

cache: false,

success: function(data) {

alert(data);

}

});

</script>

Notice the ! in the url: !ck this will accept any number of url parameters. Flexible parameters are very nice. You can pass anything. I use flexible parameters for everything. Load the parameters into a associative array, and it's very easy:

url tool.urltype := tool.load(name_array,value_array);

Then to access a param just do: url('xyz')

(you have to write tool.load etc... )