Hi 

"all users are locked " can you provide details on how users are locked out?  Are they also still locked out of Sage 100 post period end?

Thanks 

John Nichols

Sage

Hello, thank you for replying!

Unfortunately I do not have details on how the users are locked out.  Post period end they are unlocked (ie. allowed back in).  The chances that period end processes will change is slim to none.  I'm stuck with trying to clean up the odbc after the mess has been created.

I suspect that odbc queries are in process when the users are locked out and something hangs up, effectively blocking future queries.  Alternatively, the odbc remembers that the logon failed and won't forget the past failure. 

I just remembered someone sent me their notes once upon a time.  They state that state each individual user is locked by going into the Library Master > User Information

Hi , Changing the users ROLE to not allow Library Master Access does not effect ODBC access or access to Sage 100. 

Can you find out how they are allowed back in?  I'm not implying they change their PE process just trying to understand it.  Most likely the process being invoked to deny users access is causing the ODBC failure. 

Thanks 

John 

The module in the Library Master is User Maintenance.  The perpetrator is clicking the User Account Locked checkbox to lock and unlock the users at period end.

I agree, the cause is likely in how the users are being locked out.

Thanks. I'll take a look.

It sounds as if a Business Alerts process(s) is trying to connect or is connected and retrieving data from Sage 100 and is being stopped/halted by setting the user account to locked. The business alerts job is most likely hung.

Option 1
Create a new user code for use solely in Business Alerts and do not 'lock out" this user code during period end processing.

Option 2
restrict/stop business alerts jobs prior to the period end process.

Option 3
If you're using the CS ODBC driver you can try restarting the service or application on the Sage 100 server (you would still need to restart the SQL process)

John 

That's what I was afraid of - I was hoping for an option 4 that described how to clear whatever job was hung.

Option 1 - we have a dedicated user, but the period-end process person is convinced every user must be locked out

Option 2 - Unfortunately, Period end is difficult to schedule consistently (weekend, holidays, etc).  Plus, I don't think business alerts is sophisticated enough to handle all the exceptions - even if I could define them.  I wonder if I can streamline stopping the alerts to a single command though

Option 3 - Not sure what the CS ODBC Driver is.  We're using the SOTAMAS90 driver and its not on the Sage server.  Additionally access to the Sage server is highly restricted.

Thank you for the feedback. Please let me know if option 4 ever becomes realistic.

Is your dedicated user a read only user, meaning one without any roles assigned?

If not, create one specifically for ODBC access, if this is exclusively used for sage alerts, then name it as such. Do not give it any roles UNLESS you have ODBC Security enabled. Not having any roles will make sure the user can't be used to access tasks inside of sage 100. If you do have ODBC Security enabled, then create a role specifically for ODBC access to sage 100 only. In Role Maintenance, for the role for this user, uncheck everything on every tab except the ODBC Security tab.

Assuming you are on a current version, i don't believe there should be any tables that could be locked through ODBC and not having access to any tasks in sage 100 should give the user running period end the peace of mind that the alert will not interfere.

Another idea is try restarting the sage alert service instead of the server. It usually starts with either "Sage Alerts" or "KnowledgeSync" when you look for it on the Services tab of Task Manager.

There is an easier way to lock users out that might not affect ODBC.  Use the method Sage uses to lock the system during updates. 

Have your one user log in, then create a blank text file called "instlock.txt" in the server's MAS90\Home directory.  Check the Master Console to ensure nobody else is in the system, and then proceed knowing nobody else can log in, until the txt file is removed.