Hello,

When adding ODBC Settings to your package, do you prefer to use the Registry Table or the ODBC Tables?

Anyone aware of any pro/cons?

Thanks,
dreyer
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I've never really seen the point of the ODBC tables, since a) their content ends up in the registry, b) they're not used in advertising and c) their handling by my preferred tool, Wise Package Studio, has always been suspect.
Answered 10/26/2009 by: VBScab
Red Belt

Please log in to comment
0
personally I always inject them straight into the registry. Mainly because, like Ian said, I've seen some really weird behavior in WPS in the past. Installshield seems to be a bit better at it, but still, better safe than sorry.

PJ
Answered 10/26/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
The only advantage I can tell from using the ODBC tables is that it's easier to review the package and see what's in it.

Other than that I was hoping that the ODBC tables would register the registry settings for HKLM when installing per machine and HKCU when installing per user, but does not look like there's any such support.

Never tested this but could you use the HKCR hive with the ODBC registry settings via the Registry table to achieve what I mentioned above? I'm going to test this within 20 minutes, just waiting for a VMWare machine to reinstall :)
Answered 10/26/2009 by: dreyer
Purple Belt

Please log in to comment
0
No, that obviously does not work. It'll just write the settings to:

HKEY_CURRENT_USER\Software\Classes\SOFTWARE\ODBC\ODBC.INI\EDM Test T246N

[:'(]

But if you use -1 as the Root it works just fine :)

So I guess that functionality is a win for using the Registry table instead of the ODBC tables for ODBC settings.
Answered 10/26/2009 by: dreyer
Purple Belt

Please log in to comment
0
I know, it just keeps coming back, but...

self-healing / Active Setup.
Answered 10/26/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
I respect Pieter and Ian's opinions but I figure the odbc tables are there for a reason. I found that most of the "weirdness" was not having the correct driver installed, and I've also seen cases where just using the registry didn't work, i.e. the entries were there but the odbc entry was not, where the odbc tables worked.
FWIW
Answered 10/26/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
ORIGINAL: aogilmor

I respect Pieter and Ian's opinions but I figure the odbc tables are there for a reason. I found that most of the "weirdness" was not having the correct driver installed, and I've also seen cases where just using the registry didn't work, i.e. the entries were there but the odbc entry was not, where the odbc tables worked.
FWIW


Thinking one or the other is better is not of much value unless you know why. I'd definetly not consider that "the tables are there for a reason" as a valid argument to use the ODBC tables over the Registry table. Microsoft is certainly not infallible :)
Answered 10/26/2009 by: dreyer
Purple Belt

Please log in to comment
0
ORIGINAL: dreyer

ORIGINAL: aogilmor

I respect Pieter and Ian's opinions but I figure the odbc tables are there for a reason. I found that most of the "weirdness" was not having the correct driver installed, and I've also seen cases where just using the registry didn't work, i.e. the entries were there but the odbc entry was not, where the odbc tables worked.
FWIW


Thinking one or the other is better is not of much value unless you know why.

I know a hammer works better to drive a nail than a screwdriver, even if I don't know why - or, knowing why it works better is really of little value to me when I hammer the nail. but if you're really interested I'm sure it's on MSDN somewhere.

I'd definetly not consider that "the tables are there for a reason" as a valid argument to use the ODBC tables over the Registry table.


How about, "that's what they're designed for and they work better than the registry table" . :-)


Microsoft is certainly not infallible :)

well you're right about that at least :-)
Answered 10/26/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
ORIGINAL: aogilmor ORIGINAL: dreyer Thinking one or the other is better is not of much value unless you know why. I know a hammer works better to drive a nail than a screwdriver, even if I don't know why
Incorrect. If you were unable to understand and visualize the necessary physical mechanics that results in the hammer being a better tool than a screwdriver to drive in a nail you probably wouldn't pick one over the other with good reasoning (random). Knowing the hammer works better implies knowledge (or an assumption) of why it works better. Also, if you were unable to make such an intuitive decision then you probably would not be a normal functional human being.
ORIGINAL: aogilmor - or, knowing why it works better is really of little value to me when I hammer the nail.
That's correct, but it doesn't compare to my initial statement that specified thinking one is better is of no value if you don't know why.
How about, "that's what they're designed for and they work better than the registry table" . :-) Full circle, why are they better? [:D]

Sorry for being annoying, please don’t be offended [:)]
Answered 10/27/2009 by: dreyer
Purple Belt

Please log in to comment
0
I found that most of the "weirdness" was not having the correct driver installed, and I've also seen cases where just using the registry didn't work, i.e. the entries were there but the odbc entry was not, where the odbc tables worked.

I do have to admit that my reluctance to use the ODBC tables stems from a while back (about 5-6 years)when I was working with WPS . I never really looked into the why and how of it all. Basically my co-workers at that time ( I was just starting out in packaging) simply told me to "drop it and use the registry" . I have since kept that work methodology concerning ODBC entries.

I do seem to remember WPS at that time being a real pain in the ass when it came to the ODBC tables. But ofcourse things change over the years, and my knowledge has improved too.

I dare say I WOULD like to know the possible blocking factors and issues with those tables, and how to use them correctly...

PJ
Answered 10/27/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
ORIGINAL: dreyer

ORIGINAL: aogilmor ORIGINAL: dreyer Thinking one or the other is better is not of much value unless you know why. I know a hammer works better to drive a nail than a screwdriver, even if I don't know why
Incorrect. If you were unable to understand and visualize the necessary physical mechanics that results in the hammer being a better tool than a screwdriver to drive in a nail you probably wouldn't pick one over the other with good reasoning (random). Knowing the hammer works better implies knowledge (or an assumption) of why it works better. Also, if you were unable to make such an intuitive decision then you probably would not be a normal functional human being.
ORIGINAL: aogilmor - or, knowing why it works better is really of little value to me when I hammer the nail.
That's correct, but it doesn't compare to my initial statement that specified thinking one is better is of no value if you don't know why.
How about, "that's what they're designed for and they work better than the registry table" . :-) Full circle, why are they better? [:D]

Sorry for being annoying, please don’t be offended [:)]



No worries, it's good to ask questions. I'll explain (maybe poorly) why I prefer to use the tables - because ODBC entrires are more than just reg keys and values.

http://msdn.microsoft.com/en-us/library/aa370546(VS.85).aspx

http://msdn.microsoft.com/en-us/library/aa370547(VS.85).aspx

Now, the windows installer for your app is probably not going to install the drivers, but the name of the driver is still there and must be correct, the same as the installed driver.. This may be the source of some of the aforementioned problems with wps. it's been a while since I've done anything with odbc. Let's say you run your install (just a data source, no driver) and there's no driver matching DriverDescription on the PC, you get an error, whereas if you just stuff it into the registry it doesn't care about the driver.

What I do remember for sure is that using just the registry tables didn't work for some intsalls - i.e., the data source was not recognized in the odbc control panel, while using the odbc tables did, why? More time than I have to explore fully, my guess is there's a hook into the driver from the data source that gets done using the tables that doesn't get done if you just stuff the datasource in the registry. I also vaguely remember checking to see if the driver was installed before authoring entries in the ODBCDataSource table, to avoid the errors that are commonly mentioned as a reason for using the registry table.

I would do some checking and see why you're getting the errors (if you do get them with the odbc tables) rather than instantly resorting to using the registry table.

Good luck!
Answered 10/27/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
ORIGINAL: pjgeutjens
I found that most of the "weirdness" was not having the correct driver installed, and I've also seen cases where just using the registry didn't work, i.e. the entries were there but the odbc entry was not, where the odbc tables worked.
I do have to admit that my reluctance to use the ODBC tables stems from a while back (about 5-6 years)when I was working with WPS . I never really looked into the why and how of it all. Basically my co-workers at that time ( I was just starting out in packaging) simply told me to "drop it and use the registry" . I have since kept that work methodology concerning ODBC entries.

I do seem to remember WPS at that time being a real pain in the ass when it came to the ODBC tables. But ofcourse things change over the years, and my knowledge has improved too.

I dare say I WOULD like to know the possible blocking factors and issues with those tables, and how to use them correctly...
PJ

Hi Pieter, that was pretty much the methodology I followed...until it didn't work [:D]
See my reply to dreyer for a vague recall of how I did some error checking with the odbc tables...that was probably 3 years ago for me. I have not done much odbc work lately, not sure of the state of that technology, is it still common as a db connection tool? will it be around in win 7?...
-OG
Answered 10/27/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
is it still common as a db connection tool? will it be around in win 7?...

I really really wish it weren't, but so many apps here still use it... and everytime I roll my eyes and go "but this is aniquated technology..."
It's mainly the inhouse development that keeps using it here.

As for Windows 7, by God I hope they scrap it, will cause developers here to cry maybe but I really couldn't care less
Answered 10/27/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
Hi All,

So finally using ODBC tables are better than installing ODBC's through registries?
or any one faced the other way round...

thanks
sowjanya.
Answered 07/02/2010 by: sowjanya_230
Senior Yellow Belt

Please log in to comment
0
So finally using ODBC tables are better than installing ODBC's through registries?
or any one faced the other way round...


I still use the registry and it's still gonna take some doing to get me to switch.

PJ
Answered 07/02/2010 by: pjgeutjens
Red Belt

Please log in to comment
Answer this question or Comment on this question for clarity