Software Deployment

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.

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

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 :)

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.

I know, it just keeps coming back, but...

self-healing / Active Setup.

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

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 :)

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 :-)

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 [:)]

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

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!

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

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

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.

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