Bug? HTMLDB changing formats when no_translate setting!

Question

This question relates to version 1.6.1.00.02
I have my database,apache and DAD set to NLS_DATE_FORMAT='MM/DD/YYYY'
for the DAD, It is done this way...
dad calls this procedure for each connect (via "PlsqlBeforeProcedure" in dads.conf):
PROCEDURE set_dad_nls IS
BEGIN
DBMS_SESSION.SET_NLS('NLS_DATE_FORMAT','"MM/DD/YYYY"');
END;
It works and is verified if I call a procedure outside of htmldb via the URL method that just does
begin
htp.p(sysdate);
end;
it prints it in the MM/DD/YYYY format
however inside HTMLDB, the same print: htp.p(sysdate); in a pl/sql area prints in the DD-MON-YY format.
If I change my application attribute called:
"Application Language Derived From"
from "NO_NLS APPLICATION NOT TRANSLATED" to "USE_APPLICATION_PRIMARY_LAUNGAGUE"
Then I get the date inside HTMLDB returned in the MM/DD/YYYY format
However, the first setting is telling it to "not translate" yet evidently HTLMDB is translating.
What gives? Is this a bug or a misunderstanding.
I read this and still could not understand:
http://www.oracle.com/technology/products/database/htmldb/howtos/howto_handle_dates.html
In addition to the bug question (my primary question), my goal is for everything to default to MM/DD/YYYY. I have many apps, can I set MM/DD/YYYY in one place for all of HTMLDB apps (including PL/SQL areas)...or is some other method I am not following an option.

Answer 1

Meyer,
This is not a bug.
By default, modplsql pools database connections. Every page view in HTML DB uses one of these connections, does its stuff, and then the connection is returned to the pool.
HTML DB sets the NLS settings (language and territory) for every page view and submission. If it did not, then your page view would "inherit" the NLS settings from some other user's previous page view.
If your Application Language Derived From is set to "No NLS (Application not translated)", that means that HTML DB will do no processing to derive your application langauge and territory settings. But this doesn't remove the fact that you could still inherit some other user's NLS settings, so we must reset it to something. That "something" is the NLS language and territory of the database.
The language setting of HTML DB determines how the NLS_LANGUAGE and NLS_TERRITORY will be set for a particular page view. But for all page views in HTML DB, NLS_LANGUAGE and NLS_TERRITORY must be explicitly set to something.
For evidence of the previous bug in HTML DB where we did not properly reset these NLS settings, check out the first few comments at:
http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:7913917986287
So you have at least four choices:
1) Change the database settings. Via SQL*Plus, you can issue "show parameters nls" to see everything you can set.
or
2) In HTML DB, set your application primary language to some language which has territory settings corresponding to NLS_DATE_FORMAT of MM/DD/YYYY.
or
3) Add an application level before header process which performs your DBMS_SESSION.SET_NLS procedure
or
4) Add an application level substitution string, let's say called DATE_FORMAT with a value of MM/DD/YYYY, then any place you display dates (in reports, as items), set the format mask to &DATE_FORMAT. (including the trailing period).
Hope this helps.
Joel