UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Issues With Iseries Dsn-less Connections, Access 2016    
 
   
nuclear_nick
post Oct 9 2018, 09:42 AM
Post#1



Posts: 1,618
Joined: 5-February 06
From: Ohio, USA


I haven't had a fun, long-winded post in a while... lol...

We've a set of 'linked tables', using DSN-less connections, to 3 different iSeries (AS/400) 'databases'. This worked fine, until last week, when we were updated from Office 2010 to O365 - 2016.

Let's call them System1, System2, and System3.

I open the database, and open a table linked to System1, which opens without issue. Then I open a table linked to System2, and I get a 'FILE not found' message. Same message with System3.

I close the database, open it again, and open a table linked to System2, which now opens without issue. I open a table linked to System1 or System 3, and I get the error again. Same message when I reopen the database and open a table from System3 first, the message appearing on System1 and System2.

When I do the same on a computer still running A2010, this does not occur. When I open the database on a 'VMWare' 'dynamic' machine (i.e. not a 'full clone'), this does not occur. I can't go back to 2010, and I cannot rely on maintaining a connection via the 'VM' all/most of the time.

I NEED them all to work together again. My theory is that Query1 establishes a connection to Sytem1. Query2, instead of connecting to System2, attempts to use the connection to System1, which doesn't work because the table doesn't exist in System1. So... how to change connection? Something behind the scenes? I dunno.

This is getting annoying. Highly annoying.

--------------------
"Nuclear" Nick
____________
The top three reasons to hide code; 1) It's not your own. 2) It's your own, but it's so crappy you don't want anyone to see it. 3) The comments in your code would get you in a lot of trouble if ever made public.
Go to the top of the page
 
GroverParkGeorge
post Oct 9 2018, 10:07 AM
Post#2


UA Admin
Posts: 33,751
Joined: 20-June 02
From: Newcastle, WA


There might be some clues in this article.

It sounds like the connection is being cached for whichever table you open first, and then Access tries to reuse that cached connection for other tables, appropriately or inappropriately.

Can you use the Linked Table Manager to ensure that the connections are all set up properly for each database?

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Visit My Blog on Facebook
Go to the top of the page
 
nuclear_nick
post Oct 9 2018, 10:44 AM
Post#3



Posts: 1,618
Joined: 5-February 06
From: Ohio, USA


The article was somewhat helpful, as I'm already using the information from Doug's (Steele) article on DSN-less connections.

QUOTE
Can you use the Linked Table Manager to ensure that the connections are all set up properly for each database?


Wouldn't they be set up properly if I can open them, even if I have to close the database first to open up different connections?

QUOTE
It sounds like the connection is being cached for whichever table you open first, and then Access tries to reuse that cached connection for other tables, appropriately or inappropriately.


I believe you're right. For instance, if I connect to 'WM300BASD.AHASNF00' and then try to connect to 'EPBSF01.AHASNF00', it won't connect to the second with the first. I believe that is mentioned in the article you referenced. But there didn't appear to be a fix, if they were different systems, just a fix if there was only one system. Can this be 'fixed'?

--------------------
"Nuclear" Nick
____________
The top three reasons to hide code; 1) It's not your own. 2) It's your own, but it's so crappy you don't want anyone to see it. 3) The comments in your code would get you in a lot of trouble if ever made public.
Go to the top of the page
 
GroverParkGeorge
post Oct 9 2018, 11:27 AM
Post#4


UA Admin
Posts: 33,751
Joined: 20-June 02
From: Newcastle, WA


Yes and no.

It sounds like the tables may not be properly linked to the various sources. Using the LTM to configure each set would be a good thing to do.

If your setup doesn't store passwords for each connection, this won't help either.

Maybe one way to do it would be to delete all of the links and relink them again, making sure you check:

Attached File  savepwd.jpg ( 37.81K )Number of downloads: 0

--------------------
My Real Name Is George. Grover Park Consulting is where I do business.
How to Ask a Good Question
Beginning SQL Server
Visit My Blog on Facebook
Go to the top of the page
 
nuclear_nick
post Oct 9 2018, 12:16 PM
Post#5



Posts: 1,618
Joined: 5-February 06
From: Ohio, USA


Ummm...

QUOTE
If your setup doesn't store passwords for each connection, this won't help either.


We connect 637 (just counted) tables. Needless to say, I don't do it by hand, I wrote VBA to do that for me. The connection string does include user and password for each connection.

I'm assuming that this was a change in 2016, because previously this same setup was utilized in 2010, which we still have on a few computers, and it works, but in a few weeks IT should have all of our machines converted, so I have about two weeks to come up with a solution. So far the solution is to log off and log on again. I'm really hoping for a different solution, or I'm going to be really busy for the next few weeks.

Fun fun fun.

--------------------
"Nuclear" Nick
____________
The top three reasons to hide code; 1) It's not your own. 2) It's your own, but it's so crappy you don't want anyone to see it. 3) The comments in your code would get you in a lot of trouble if ever made public.
Go to the top of the page
 
nuclear_nick
post Oct 10 2018, 06:09 AM
Post#6



Posts: 1,618
Joined: 5-February 06
From: Ohio, USA


After some poking and prodding... apparently the issue did not occur when we moved back to a DSN connection.

Sigh.


--------------------
"Nuclear" Nick
____________
The top three reasons to hide code; 1) It's not your own. 2) It's your own, but it's so crappy you don't want anyone to see it. 3) The comments in your code would get you in a lot of trouble if ever made public.
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    16th October 2018 - 10:38 PM