Re: .NET Data Provider and CPE3426

From your post I get that the QZDASOINIT jobs on the I are simply pgms
that serve up data for either ODBC and/or OLE/db.

Yes. QZDASOINIT jobs implement an interface known as SQL CLI which is an
abstraction and extension of the ODBC protocol.

Our pgmr contends that the .NET provider (OLD/db) is much faster than

ODBC. Wondering why that would be the case if, in fact, it is true.

I don't know if that's true either. If so, the performance gain would only
be applicable to processing performed in Windows - not IBM i.

Also wondering if the db connectors in 5733OPS (Python and node.js) would

serve up data faster than the lugubrious ODBC.

Keep in mind that ODBC is a specification - implementations may vary.
OLE/db adheres to much of the ODBC specification. The SQL CLI interface
implemented on IBM i adheres to it. The interfaces provided with node.js
and Python adhere to it.

Distributed architecture always makes it hard to pinpoint performance
bottlenecks. The root of the problem is more often what applications are
doing as opposed to what "drivers" they're using.

As for making this "visible" it is a request on my part to be able to

respond to Q's from the .NET folks as to why we are crashing with the
CPE3426 msg.

Put that back on the .Net programmers. Ask them what they are doing to
cause a socket reset on active connections?