Unicode string now returned from Stored Proc., used to be ANSI.

Question

Using ADO to connect VB6 to Oracle 8 stored procedures used to return strings in ANSI format. At some point in the last year or so, strings suddenly began to be returned as Unicode, unreadable by VB.
Same problem now occurs using VB.Net and ODP.Net; I need to support both VB6 and .NET versions.
Why are strings being encoded differently than before? Has anybody else seen this problem? What can be done?
The NLS_LANG registry entries on the server and client machines match each other. Some of our installed base of customers reported this change, too.
Below are some demonstration code examples.
Stored procedure looks like this:
CREATE OR REPLACE PROCEDURE MyStoredProc
(sMyMsg IN OUT VARCHAR2) AS
BEGIN
     sMyMsg := 'My test string';
RETURN;
END;
On the VB6 side, my code looks like this:
Dim vParam As Variant
Dim cmdExecute As ADODB.Command
Dim pParam As ADODB.Parameter
Set cmdExecute = New ADODB.Command
cmdExecute.CommandType = adCmdStoredProc
cmdExecute.CommandText = "MyStoredProc"
Set pParam = cmdExecute.CreateParameter("PARAM1", vbString, adParamInputOutput, 0, vParam)
cmdExecute.Parameters.Append pParam
cmdExecute.ActiveConnection = ADOConnect
cmdExecute.Execute
vParams = cmdExecute.Parameters(0)
Result of VB code is that vParams now contains a Unicode string.
Any suggestions as to what's happening, where the problem might be, what to do about it, or where else to post this question (I'm not sure which Forum is the best place to look for answers) would be appreciated.
Is "force SQL_WCHAR" relevant to this problem? If so, what does that mean and how/where do I apply it?

Answer 1

The Force WCHAR option forces the ODBC driver to
report columns and return data as Unicode. If that
is checked, you probably want to uncheck it.But how do I do that? I can't find any documentation for a SQL_WCHAR option. Where do I go to read/change the current setting of this switch?
What character set is your client & database?NLS_LANG, for both machines, is "AMERICAN_AMERICA.WE8ISO8859P1". BTW, the client is 9.2, but the database is version 8.1.7. I'm fairly certain that the problem also existed when the client was also running ver. 8.