Oracle DB Version: 9.2.0.1
DB character set : UTF8 (not AL32UTF8)
Client: Oracle Forms 6i Patch 14 in Client/Server mode.
Client NLS_LANG: AMERICAN_AMERICA.UTF8.

Going through a nightmare since we moved from Oracle 8.1.7 with Forms
6.0 to Oracle 9.2 with Forms 6i!!

After much work (nls_lang, unicode fonts...), we can see UTF8 tables
in Forms with their UTF8 characters OK, but when we try to EDIT one
single textbox, just in the moment we strike a key (no matter if it is
DEL, or another one) TNS-12571 appears!!

If we issue a single update command in, for example,
WHEN_NEW_FORM_INSTANCE trigger (UPDATE TABLE_A SET
COLUMN_A='Blah,blah, blah...' WHERE Blah, blah, blah) the update works
OK and the data is updated in the DB.

Searched metalink with no results.

Any ideas?

Thanks in advance.

Carlos wrote:

No bother looking up the error for you :-v
12571, 00000, "TNSacket writer failure"
// *Cause: An error occurred during a data send.
// *Action: Not normally visible to the user. For further details, turn
// on tracing and reexecute the operation. If error persists, contact
// Oracle Customer Support.
--
Regards, Frank van Bortel

Thank you Frank but... just tell me something that I didn't already
know!! ;-)

Looked up the Oracle error messages and the metalink references (and I
have seen your quote too). But my note was meant to try and find
someone who has experienced this before. Nobody seems to have faced
this problem. Maybe we are some kind of 'oracle software explorers'
stepping territories not stepped before?

BTW. If we try to insert some new rows from the developer window and
we hit the 'save' button, it displays 'working...' with no results.
Tracing the session, it appears to execute a single INSERT statement
with bind variables (some kind of INSERT into TABLE (row1, row2...)
values (:value1, :value2...) and it just hangs.

Note that it must be related with some window activity, since ALL SQL
statements written inside Forms triggers work OK!!

There would be so much to talk about the Oracle politics of forcing
its customers' architectures: 'Move from C/S to three tier with our
OAS'. 'We will not support C/S architectures anymore'.

BTW. Patch 15(!!) neither seems to fix this problem... Maybe in patch
16... or 17. Oracle looks more and more like Microsoft, though
Microsoft releases the patches for free, no 'metalink' required.

Kind regards.

Carlos.

Frank <fbortel (AT) nescape (DOT) net> wrote

Carlos wrote:

Ok, so you searched Metalink with results - at least the error
became clear. And that was not clear in your post.

What client do you use? Perhaps the 9i client (more specific
the network layer) will resolve the error condition.
Character mapping is done in the network layer.

Just a wild guess, tho
--
Regards, Frank van Bortel

We've found that this weird error occurs when the Forms 6i client
tries to block a row. If we set up blocking method 'immediate' the
error raises when editing text box (just when forms tries to block the
row). If the blocking is deferred the error raises when pushing the
'save' button (again, when forms tries to block the row).
No difference if we block by ROWID or by Primary Key.

Set tracing on, and this is what it shows :

ntt2err: soc 496 error - operation=6, ntresnt[0]=530, ntresnt[1]=54,
ntresnt[2]=0
ntt2err: exit
nttwr: exit
nspsend: transport write error
nspsend: error exit
nserror: entry
nserror: nsres: id=0, op=67, ns=12571, ns2=12560; nt[0]=530, nt[1]=54,
nt[2]=0
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdofls: error exit
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
nsdo: nsctxrnk=0
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: error exit
nioqsn: Error: Inconsistent trace parameters line: 836
nioqper: error from nioqsn
nioqper: nr err code: 0
nioqper: ns main err code: 12571
nioqper: ns (2) err code: 12560
nioqper: nt main err code: 530
nioqper: nt (2) err code: 54
nioqper: nt OS err code: 0
nioqer: entry
nioqer: incoming err = 12150
niqme: entry
niqme: reporting ns (2) error: (12571) as rdbms err (12571)
niqme: exit
nioqce: entry
nioqce: exit
nioqer: returning err = 12571
nioqer: exit
nioqsn: returning error: 12571
nioqsn: exit
nioqbr: entry
nioqbr: state = normal (0)
nioqsm: entry
nioqsm: Sending break packet (1)...
nsdo: entry
nsdo: cid=0, opcode=67, *bl=1, *what=17, uflgs=0x100, cflgs=0x3
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
nsdo: rank=64, nsctxrnk=0
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: nsctx: state=8, flg=0x420d, mvd=0
nsdo: gtn=127, gtc=127, ptn=10, ptc=2047
nsdofls: entry
nsdofls: DATA flags: 0x0
nsdofls: normal exit
nsdo: sending NSPTMK packet
nspsend: entry
nspsend: plen=11, type=12
nttwr: entry
ntt2err: entry
ntt2err: soc 496 error - operation=6, ntresnt[0]=530, ntresnt[1]=54,
ntresnt[2]=0
ntt2err: exit
nttwr: exit
nspsend: transport write error
nspsend: error exit
nsdo: error sending NSPTMK packet
nserror: entry
nserror: nsres: id=0, op=67, ns=12571, ns2=12560; nt[0]=530, nt[1]=54,
nt[2]=0
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
snsbitcl_ts: entry
snsbitcl_ts: normal exit
snsbitts_ts: entry
snsbitts_ts: acquired the bit
snsbitts_ts: normal exit
nsdo: nsctxrnk=0
snsbitcl_ts: entry
snsbitcl_ts: normal exit
nsdo: error exit
nioqsm: send-break: failed to send break...
nioqper: error from send-marker
nioqper: nr err code: 0
nioqper: ns main err code: 12571
nioqper: ns (2) err code: 12560
nioqper: nt main err code: 530
nioqper: nt (2) err code: 54
nioqper: nt OS err code: 0
nioqer: entry
nioqer: incoming err = 12152
niqme: entry
niqme: reporting ns (2) error: (12571) as rdbms err (12571)
niqme: exit
nioqce: entry
nioqce: exit
nioqer: returning err = 12571
nioqer: exit
nioqbr: returning 12571
nioqbr: exit
nioqds: entry
nioqds: disconnecting...

And the errors are:

Oracle errors:
12571: TNS-12571 TNSacket writer failure
12560: TNS-12560 TNSrotocol adapter error
12152: TNS-12152 TNS:unable to send break message

NT errors:
530: Logon Failure. (Account time restrition violation) (An attempt to
log on was made and rejected because the user tried to log on before
or after the hours that the user is allowed to !!!????)
54: Network Number conflicts with an existing router. (Source:
Appletalk!!)

This DOES NOT happens when issueing SQL commands from Oracle Forms
(inside built-in packages).
This DOES NOT happens when issueing SQL commands from SQL*Plus.

We have tried almost everything with no results (even increased the
licensing number at the W2K Server because the RPC's).
Tired of reading every documentation related to this...

....and, to my desperation, developed a very simple ACCESS 2000 front
end via ODBC and It worked with no problems from the very first
time!!!

So, please HEEELLLPPP!!!

Regards.

Carlos wrote:

Nope - doesn't ring bell - sorry.
Tried logging an iTar? Comes up with more suggestions
than I ever managed to find searching Metalink
--
Regards, Frank van Bortel

For those who were intrigued by our migration adventures... finally we
did it!

I've lost the count of the trace files we've examined.
I've lost the count of the number of installations/deinstallations
we've made (Forms 6i: Server and Developer, with bizarre results
depending on the installation order).
I've lost the count of the forum posts, metalink articles, OTN
articles, miscellaneous documentation we've read.
I've lost the count of the patches we downloaded and applied.
I've lost the count of the different tests we made (even changing the
network connection or installing it all on another machine).
I've lost the count of the telephone calls asking for help, including
ex-colleagues, and Oracle itself.
I've lost the count of the parameters and registry keys we changed...

....and always the f***ing 12571 when attempting to block a row from a
Form (in sql*plus we actually could create the same CURSOR... FOR
UPDATE with no problems in the same W2K box).

Well, ... and finally, the solution:

1.DROP the DATABASE.
2.APPLY PATCH 9.2.0.4 (250 Mb).
3.RE-CREATE THE DATABASE (Don't forget the 150 Mb for Shared_Pool and
Java_Shared_Pool EACH!!, after a couple of flawed attempts)
4.CREATE AND POPULATE THE TABLES.

And misteriously... everything turns to work OK!!

It *only* took us about a month to work it out!

No more comments.

Now, let's go for the next obstacle.

Carlos.