PDA

View Full Version : New Connection ID class.



Michael Mullan
7-Jan-2017, 07:37 AM
As I mentioned in another post, I used to keep connectionIDs in MSSQLDRV.int. When upgrading to 19.0 I did not move the connection ID to MSSQLDRV in the new programs folder, I added it to the connections.ini using the link in the dashboard. That worked, but the program wouldn't run. Shock Horror!

I actually did then RTFM, and discovered that all I needed to do was add

Object oConnection is a cConnection
Set pbLoginOnOpen to False
Use LoginEncryption.pkg
Use DatabaseLoginDialog.dg
End_Object

before (or inside) the oApplication object.

Job Done. Connections made, no hassle.

I like it.

MM.

Stephen W. Meeley
7-Jan-2017, 10:18 AM
Michael,

Do you think the migration utility should have added that code? Or at least logged that it didn't exist?

Michael Mullan
7-Jan-2017, 11:34 AM
In a perfect world...

The migration utility would read the previous version's MSSQLDRV.int (it's migrating, so it knows about the original version). If any dfconnid entries were found, then it would migrate those into the INI file for the new workspace.

Then it would add the above code as a child of oApplication in the project files it found in the workspaces. (My oApplication object is not in the SRC file, its ihs a"precompileHeader.PKG" so you can't depend on finding it in an .SRC file. :-) ! )


If you can't do the first bit, then he second bit should only be done automatically IF the cConnection class does not choke on connection ID's still in mSSQLDRV.int, or no connection ID's


Fair?

John Tuohy
8-Jan-2017, 04:57 PM
Michael,

It's probably best to see how the experience of moving to managed connections goes before we commit to an automatic migration scheme. Our current goal was to make sure that existing applications, including those using connection IDs work as they did and that the experience of moving to 19.0 will be no different than moving to prior releases. Developers came up with a variety of ways to handle connection IDs it may be difficult for us to assess how to migrate from all of these different approaches.

We have considered automatically adding the new code required for managed connections. This should work with all existing applications, but the key word here is "should". Anytime we add code, even code that is not used, to an existing application there can be issues. While that is not a bad thing, it's not the first thing we wanted developers to encounter.

Also, once you've done that first manual conversion (as you did) you may decide that this is not that bad. It forced you see where the changes are and, once you've done it the first time, it's pretty easy to do.

-John

Michael Mullan
8-Jan-2017, 07:15 PM
True. But some of us have a shed load of workspaces to migrate.

Id much rather remove extra code, and configure, than have to add it in, leaving me open to doing it wrong..

V
in general I love how DAW wizards write code that works. In fact it's my go to debugging tool of choice.

;)