SDerrick
19th May 2014, 09:52
Hello,
We need to change an index on a table, specifically to tick the "duplicates allowed" box however, this is whinh430 - shipments. A table that is used 24 hours a day almost. To do this, by installing a PMC solution and then converting to runtime, is it necessary to ask all users to log out of LN, or can it be done during working hours?
Thanks
Simon
bhushanchanda
19th May 2014, 11:48
Hi,
Its not advisable to change anything in the standard tables. And yes, its always better to do any CRDD in single user mode.
ulrich.fuchs
10th June 2014, 18:55
@bhushanchanda: There is nothing that speaks against changing standard tables, if it's required from a business perspective and the developer knows what he's doing. In fact, against common believe, this is a type of customization that is abosolutely cheap in terms of software maintainance and compatibility with standard solutions. (However I agree that allowing duplicated in an index where the standard does not allow duplicates might be a bad idea).
But the question was if there is downtime required if a (I assume standard) PMC solution requires that change. The awnser, unfortunatly is: it depends. On the database and on the porting set version. Simon, if you're lucky, the database drive will send an "alter index" statement to the database. That still might lock the whole table and block users, but it might be a matter of minutes. User that were online will encounter errors after the change, but when logging out and in again, those errors should be gone.
However if you're out of luck, LN will export the table to a flat file, drop it, and recreate it from the file. Then all users need to leave the system, because otherwise LN can't drop the table. You may even end up with a corrupted data dictionary in such a situation.
So as a rule of thumb: Better plan that any data model change requires downtime.
best regards
Uli
benito
11th June 2014, 15:06
Request for a downtime period, say 30 minutes to an hour, then convert to runtime with Re-org checked. Better safe than sorry. As a business they should understand that sometimes we need to do this.