PDA

View Full Version : Error 75 pbLoginOnOpen=False



raveens
19-Jan-2017, 05:27 PM
Hi DAW,

If I Set pbLoginOnOpen=False then I get error 75.
else its fine.



C:\RP\800\ProgWin\TestConnection.exe
Can't open table. Not logged in to DSN=DFCONNID=RPCONN. LoginOnOpen = 0 Table = PARAM (248)

Error: 75
Error Source = DB2_DRV.Open

MSG_ONWORKSPACEOPENED (7809) - oApplication (39) - at address 79068
MSG_DOOPENWORKSPACE (7806) - oApplication (39) - at address 38689
MSG_END_CONSTRUCT_OBJECT (459) - oApplication (39) - at address 38717
[start] - at address 79074


Sample Program:



Object oApplication is a cApplication
Set peHelpType to htHtmlHelp
Object oConnection is a cConnection
Set pbEncryptPassword to False // simple test
Set pbLoginDialogRequired to False
// Bug here
Set pbLoginOnOpen to False
End_Object

Set psAutoOpenWorkspace to "XLS.Helix.DB2.ws"

Procedure AutoConnect
Handle hoWorkSpace
String sConnectionIni

Get phoWorkspace to hoWorkSpace
If (hoWorkSpace) Begin
Get psConnectionIni of hoWorkSpace to sConnectionIni
If (sConnectionIni="") Begin
// Read DFCONNECTIONS from WS file
Get psWorkspaceWSFile of hoWorkSpace to sConnectionIni
Set psConnectionIni of hoWorkSpace to sConnectionIni
Showln "Using ConnectionIni=" sConnectionIni
End
End
Forward Send AutoConnect
End_Procedure

Procedure OnWorkspaceOpened
Open PARAM
Open CodeMast
Open CodeType
End_Procedure

End_Object

John Tuohy
20-Jan-2017, 01:32 PM
When you set pbLoginOnOpen to False (which is a good choice) it specifies that you must be logged into the database server before you can open the table. If you are getting an error, this means that your auto-connect failed. I am not sure why that is.

You will need to debug into AutoConnect to see what is going on. My guess is that your managed connections are not being read properly (or not found at all, perhaps because it is not finding the file or the file has no connection sections). Therefore you get no login and you get this error. My guess is stepping through the cConnection LoadStoredConnections function will reveal what is going on.

Also note that both psConnectionIni and AutoConnect are private in cApplication. You can move these to cConnection where they are public. Perhaps we should change their cApplication names when this doesn't happen.

Let me know what you find.

-John

raveens
21-Jan-2017, 08:43 PM
Hi John,

Found the issue - the problem is the way driver created the INT versus the way the cConnection class logins

Our connection id is RPCONN

The cConnection login as "DFCONNID=RPCONN" (See: LoginConnectIdBase and BasicLogin) it basically does a "Login DFCONNID=RPCONN '' '' DB2_DRV"

But, the INT files are/were created with a SERVER or login of "SERVER_NAME DSN=DFCONNID=RPCONN"

Technically, 2 different IDs hence why I'm getting the error 75 when I set pbLoginOnOpen to False

I tried modifying the Table using the Studio in DF19, to see if the INT would be written differently but the server was still written as "SERVER_NAME DSN=DFCONNID=RPCONN"

I then manually modified the INT to "SERVER_NAME DFCONNID=RPCONN" -that worked!

Not sure its a driver INT issue or the cConnection class - If I had to choose a LOGIN string format then the cConnection format makes more sense.

Samuel Pizarro
22-Jan-2017, 06:52 PM
But, the INT files are/were created with a SERVER or login of "SERVER_NAME DSN=DFCONNID=RPCONN"

I never saw a int like this before..

where did it come from ?
1. previous workspace migrated to 19.0?
2. dat files converted to db2 on 19.0 ?
3. table created under studio already using db2 driver to create the table directly on db2 db ?

raveens
22-Jan-2017, 07:36 PM
Hi Samuel,

These INT files were originally converted back in 2009 using probably CK 5.1 when DFCONNID was first introduced, and ever since been brought forward thru the revisions of DataFlex.

I thought it weird too but they worked so I never questioned it and put it aside as a DB2 CK thingy.

How does your INT "SERVER_NAME" attribute look like?

Samuel Pizarro
26-Jan-2017, 01:30 PM
Hi Raveen

Sorry for the long delay in answering this. Had issues with my dev env and only today was able to get back to this.



How does your INT "SERVER_NAME" attribute look like?

Before 19.0 , with managed connections:
For tables Not Using ConnectionIDs:


SERVER_NAME DSN=SERVICOS;UID=d******;PWD=******

For tables using ConnectionIDS (I use to define the connections IDs into a local copy of the DB2_DRV.int located under data directory of the workspace)

SERVER_NAME DFCONNID=Servicos_ConID

------

I converted this 18.2 workspace to 19.0 alpha 1, and the INTs were not touched. They remain exactly like they were originally, keeping the backward compatibility.

But now, this makes me think. What is the procedure to migrate old-fashion .INT SERVER_NAME definitions to start using the new Managed Connectins on 19.0 after the workspace has been migrated?

I did not find anything related to this task in the help.

Regards

Stephen W. Meeley
26-Jan-2017, 02:59 PM
Sameul,

Once you have the managed connection set up in the workspace you use the connection wizard to refresh and the .int files will be changed over to use the new managed connection.

Samuel Pizarro
26-Jan-2017, 03:08 PM
Thanks Stephen.

Can we have a section in the help for that ?
something like " Migrating legacy SQL tables to Managed Connections" or whatever better names you guys can come up with!

Thanks

Stephen W. Meeley
26-Jan-2017, 03:12 PM
It's in the works (we're only on Alpha 1 :rolleyes:)

Samuel Pizarro
26-Jan-2017, 03:13 PM
Oh sure!

nice to hear it was already in the plan!!!

Thanks again

raveens
26-Jan-2017, 09:53 PM
Hi Stephen,

Should have read this first !

I manually did a "Find & Replace" of "DSN=DFCONNID=" to "DFCONNID=" for all INT files.

All is good now !