We have an MAS200 Database residing on an NT server. (We've recently upgraded from MAS90.) To access this database for a few VB apps and through MS Query, we use an ODBC link:
Data Source: SOTAMAS90
Database Directory: \\Ugies-mas200\BEST\MAS90
Well, normally, we can access this stuff "fairly" well through the VB apps and MS Query, although it is EXTREAMLY slow. However for the last week or so (we did the upgrade about 3 weeks ago), the ODBC connections seem to be touch and go. We have connection all morning, then a user will come over and say the program either froze on her or gave her an SQL error. She can still get into MAS200 itself though. (This is several users having this problem, not just one.)
Sometimes it is just that user, sometimes it is several people. Then all of a sudden, while we're trying to look into the problem, everything starts to work fine again.
Another thing worth noting. Early last week we had a power outage that seemed to have corrupted a file or two in MAS200, and we restored that from tape. After doing that, we had problems with users' ODBC link that kept resetting the Database directory to \\Ugies-mas200\MAS90 instead of \\Ugies-mas200\BEST\MAS90. We'd manually change it, only to watch it reset to the incorrect path after the user opened MAS200. We discovered that this was related to the SOTA.ini file stored in the client's Program Files Directory. We corrected the path name there, and the ODBC seemed to stay the same after that.
Anyone have even the slightest idea what we should be checking here?
Also, does anyone know a faster, better way to connect to MAS200 instead of ODBC. It is so slow, that we're having problems determining if the PC is locked up, or if it's still off in "MAS200 World".
I am running MAS 200 and haven't had any problems...I did decide not to go with the SQL install to avoid the overhead of maintaining the system. As far as the SQL issues...have you connected to MAS on the server and had any problems. That would help narrow you focus down to a network or configuration problem.
I think youre supposed to create a duplicate ODBC source in order for it to run decent (but even then its super slow). The standard DSN that you mentioned above is supposed to be reserved for the clients/server software by itself. The support site has a kb explaining how to create a "silent" odbc connection, check it out.
For me, its first time around with this system, and I can't say that I'm impressed from a technical standpoint. We are probably going to end up dumping data to a SQL server for extended report writing capabilities.
I worked for a company that had one of the largest MAS200 databases known to reside in MAS. We were running SQL and never had any problems. Had very good support from Best as well. It sounds more like your server installation is not very good.