Well, we finally figured out what the problem was. It had to do with 32-bit System DSN's versus 64-bit System DSN's. The version of Microsoft Access we are using is 2010, 32-bit. The operating system is Windows 7, 64-bit. When you run the ODBC Admin app from the control panel, you are working with 64-bit System DSN's. When we ran Microsoft Access, and we were prompted to select a data source, it would only show us the 32-bit System DSN's. Somewhere along the way, the 32-bit and 64-bit DSN's were duplicated and there was a 32-bit version with the same name as the 64-bit version. So, when we ran the ODBC Admin app from the control panel and we thought we were changing the library list correctly, we were changing the 64-bit version when MS Access was using the 32-bit version. Here is a link to an article that explains it further. http://support.microsoft.com/kb/942976

The reason I was able to change the library list successfully on my PC was because I was using a User DSN as opposed to a System DSN. The article talks about this as well.

Dean Eshleman,
Everence Financial

On 12/14/2012 2:50 PM, Dean Eshleman wrote:

OK, assuming your profile doesn't have *ALLOBJ authority how does the QZDASOINIT job's library list compare to one of your non-ODBC job's library list? I'm asking because it sounds like you have more authority than the user. At least enough additional authority so that Access can change the OZDASOINIT job's library list.

I don't have *ALLOBJ, but I do have command line access where the user doesn't. The user is sure that they have done this in the past where they changed the data source definition to add a library and then everything worked as expected. Thanks for the tip about changing the message level. I'll probably try that next to see if anything shows up in the job log.

Dean Eshleman
Everence Financial

On 12/14/2012 2:33 PM, Monnier, Gary wrote:

OK, assuming your profile doesn't have *ALLOBJ authority how does the QZDASOINIT job's library list compare to one of your non-ODBC job's library list? I'm asking because it sounds like you have more authority than the user. At least enough additional authority so that Access can change the OZDASOINIT job's library list.

You can try killing your QZDASOINIT job, change all running QZDASOINIT jobs to message level 4 0 *SECLVL, change the jobd QZDASOINIT starts with to be 4 0 *SECLVL also and run you test again. You might find something in the joblog.

When the user was trying it, it didn't show up in the library list for their QZDASOINIT job. When I tried to duplicate the problem on my PC, I was able to get TEST12 to show up in the library list of my QZDASOINIT job. Does that make sense?

One of our users is seeing some strange behavior with their ODBC connection to the IBM I using Microsoft Access. He added a new library to the Data source definition called TEST12. Next, he went into MS Access and tried to link to some tables in the new library. After selecting the correct Data source, it displays a list of files to select from. However, no files from TEST12 are in the list. I verified that he had authority to the files. Authority is thru an authorization list. What is really strange is when I look at the library list of the QZDASOINIT job, it doesn't have TEST12 in the library list. In fact, he changed the data source and removed a library and tried it again. The library that was removed, still showed up in the library list of the server job. It seems to be holding onto a previous connection or something. We tried having him reboot his PC, but still no TEST12 in the library list.

I have tried to duplicate his problem, but have not been successful. I change the library list for my data source, and it handles it correctly. I made sure that my authority to the files was the same as his, and MS Access showed me the files just fine. Anyone have any ideas ?

________________________________________
Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmission errors in the future. Thank you.
_______________

________________________________________
Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmission errors in the future. Thank you.
_______________

________________________________________
Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmission errors in the future. Thank you.
_______________

______________________________________________________________________
Confidentiality Notice: This information is intended only for the individual or entity named. If you are not the intended recipient, do not use or disclose this information. If you received this e-mail in error, please delete or otherwise destroy it and contact us at (800) 348-7468 so we can take steps to avoid such transmission errors in the future. Thank you.

This mailing list archive is Copyright 1997-2015 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact