Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 264 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 992 SQL General
- 385 SQL Performance
- 33 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Safety measures in deployment window (BC/AL)
Christoph_G
Member Posts: 3
Hi Guys,
Happy New Year!
Since the introduction of AL apps it has become even more critical to prevent data changes in the system during app deployment windows.
Changes sources could be users, web services, job queues.
During app installation some of the existing ones are getting uninstalled and during that time their fields and code are unavailable, so any processing launched during that period can result in severe data loss or inconsistency. Thus in each window we must make sure no users are logged in, job queues are not running, web services are not used.
Normally we solve it by turning off appropriate services, but maybe you have some more elegant and quicker way of "locking" the system to unwanted changes.
I'd be grateful for any ideas. Thank you.
Happy New Year!
Since the introduction of AL apps it has become even more critical to prevent data changes in the system during app deployment windows.
Changes sources could be users, web services, job queues.
During app installation some of the existing ones are getting uninstalled and during that time their fields and code are unavailable, so any processing launched during that period can result in severe data loss or inconsistency. Thus in each window we must make sure no users are logged in, job queues are not running, web services are not used.
Normally we solve it by turning off appropriate services, but maybe you have some more elegant and quicker way of "locking" the system to unwanted changes.
I'd be grateful for any ideas. Thank you.
0
Answers
Thanks for the prompt reply.
If you mean switching it on SQL Server then it's not always an option, as in case of some customers we don't have constant admin access to db servers.
Thus we're looking for some option excluding the need to do anything on db side.
However session management commands don't seem to work in every case. It happened that STOPSESSION in RTC sometimes did not kill session (MS docs say it can only kill idle/inactive sessions, but I've got an impression sometimes it had problem with idle sessions, too).
In BC Web Client sessions sometimes even seem not to care about Powershell commands raised as admin on middle tier server. What's even worse some sessions reappear even after service restart [sic!].