com-handle failing on some clients not others?

[cthulhugeek]

Hello fellow Progress Talkers,

I have this weird problem. The following code runs fine on 13 out of 15 clients. On 2 machines I am getting the following error.

unable to set com-handle property (5677)

The code is the same as it is on the network, I can not find what makes the other two machines different. One thing that does make them the same is that only these two machines were getting the blue sceen of death while in progress, and it mentioned portcls.sys was the offending program. From what I have seen on the internet portcls.sys has to do with sound, so I shut off the sound card, seeing they dont use it and the blue screens went away. Any ideas?



The details:

progress 9.1D running on windows 2003 server
progress 9.1D character clients running on 15 identically configured dell precison 380's running windows xp SP 2.

Any ideas would be helpful.

Almost forget! Here is an exerpt from the code.


DEFINE VARIABLE ObjRecordSet AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE ObjConnection AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE ObjCommand AS COM-HANDLE NO-UNDO.
DEFINE VARIABLE ODBC-DSN AS CHARACTER NO-UNDO.
DEFINE VARIABLE ODBC-SERVER AS CHARACTER NO-UNDO.
DEFINE VARIABLE ODBC-USERID AS CHARACTER NO-UNDO.
DEFINE VARIABLE ODBC-PASSWD AS CHARACTER NO-UNDO.
DEFINE VARIABLE ODBC-QUERY AS CHARACTER NO-UNDO.
DEFINE VARIABLE ODBC-STATUS AS CHARACTER NO-UNDO.
DEFINE VARIABLE ODBC-NULL AS CHARACTER NO-UNDO.
DEFINE VARIABLE ODBC-CURSOR AS INTEGER NO-UNDO.

/* Create the connection object for the link to SQL */
CREATE "ADODB.Connection" ObjConnection.
/* Create a recordset object ready to return the data */
CREATE "ADODB.RecordSet" ObjRecordSet.
/* Create a command object for sending the SQL statement */
CREATE "ADODB.Command" ObjCommand.
ODBC-QUERY =
"SELECT * from plateinv where stocknumber = '" + ptag# +
"' and heatnumber = '" + pheat# +
"' and platetype = 2 ORDER BY createdate DESC".
ObjConnection:Open ("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=P:\Database\P~
ronest7.mdb;Mode=Read;Persist Security Info=False",,,0).
/* Check for connection errors */
IF ( ERROR-STATUS:NUM-MESSAGES > 0 ) THEN
MESSAGE "ERROR".

ASSIGN ObjCommand:ActiveConnection = ObjConnection
ObjCommand:CommandText = ODBC-QUERY
ObjCommand:CommandType = 1 /* adCmdText */
ObjConnection:CursorLocation = 3 /* adUseClient */
ObjRecordSet:CursorType = 3 /* adOpenStatic */
ObjRecordSet =
ObjCommand:EXECUTE(OUTPUT ODBC-NULL, "", 32 )
ODBC-RECCOUNT = ObjRecordSet:RecordCount.
IF NOT ODBC-RECCOUNT > 0 THEN RETURN.
xlngth = ObjRecordSet:FIELDS ("platelength"):VALUE.
xwdth = ObjRecordSet:FIELDS ("platewidth"):VALUE.
xwgt = ObjRecordSet:FIELDS ("weight"):VALUE.
platepath = ObjRecordSet:FIELDS ("platepath"):VALUE.

 

[KnutHandsome]

I can not find what makes the other two machines different.

Well, it is the most likely explanation, ie. they are differently configured, or running the application differently.

Finding out how they are different is a job for your sys admin people, but you could (for instance) try diffing the output from an auditing progam like winaudit.

One thing that does make them the same is that only these two machines were getting the blue sceen of death while in progress, and it mentioned portcls.sys was the offending program.
From what I have seen on the internet portcls.sys has to do with sound, so I shut off the sound card, seeing they dont use it and the blue screens went away. Any ideas?

It sounds like the sound card drivers (portcls) are the culprits, not progress.

Try downloading the latest versions of the drivers from the manufacturers (not Microsoft), and reinstalling on 'bad' machines.

However, it would be worth checking the exact build versions of the drivers and OSes (and Progress, and anything else) on 'good' and 'bad' machines.

As for your code, I see no releasing and deleting of objects, including before your RETURN. This will eventually cause memory problems (leaks, illegal access, etc.).

However, if you are executing the same code in the same way in allegedly the same environment, it's probably a SysAdmin problem, so get them to help.

 

[it@flude.co.uk]

One thing you could do is put messages in (old-fashioned though it is) to find out exactly where the problem occurs and whether it occurs in the same place on both machines.

That might give you an idea of what is failing and perhaps where to look.