Igor KorolyovНасчёт "инструкции" - ты видел хоть одного пользователя который прочёл
инструкцию? Или ты считаешь что перед большим начальником пройдёт отмазка
типа "в инструкции это было описано"?
1.Сдача проекта только после инструктажа пользователей
2.Или вы делаете все для большого начальника? Чтобы показать все возможности и тонкости приложения, понадобиться минимум неделя консультаций (обучения). Чтоб такого не было - инструкция просто необходима!
3.Мало того по участкам (если это какая-то сложная задача,
раскиданная по АРМам)
Igor KorolyovИли ты считаешь что перед большим начальником пройдёт отмазка типа "в инструкции это было описано"?
Я видел такую практику, и считаю ее неплохой -
Инструкция выдается каждому сотруднику,
на титульном листе присутствует:
"Ознакомлен Подпись Пупкин".
И я не только считаю, А ПРОВЕРЕНО НА ПРАКТИКЕ -
КОГДА ТЫКАЕШЬ ПАЛЬЦЕМ В ИНСТРУКЦИЮ ПОЛЬЗОВАТЕЛЯ
В ТО МЕСТО ГДЕ ЭТО ВСЕ ОПИСАНО - "КРАСНЕТЬ" ТЕБЕ УЖЕ
НЕ ПРИДЕТСЯ.
Или, если какой-то специалист заказчика во время внедрения в отпуске,
то при выходе он уже выпал из пачки? Прочитает и все поймет!
Если там какой-то захудалый пользователь - это их проблемы.
И ни один БААльшой начальник меня не упрекнет в недоработках.
Приложение пишется по ТЗ (или на худой конец в Предмете Договора),
которое составляется за подписью Бальшого Начальника.
Igor KorolyovАга - тогда тебе надо срочно читать про consistent reads - ибо для ЧТЕНИЯ
тоже иногда нужны блокировки. Конечно в Oracle с этим получше - т.к. он
версионник
АГА, АГА - я и работаю с Oracle, с MSSQL только экпериментирую.
Кстати, понятие "версионник" - к Ораклу отношения не имеет. Это чисто MSSQL
READ COMMITTED
Specifies that statements cannot read data that has been modified but not committed by other transactions. This prevents dirty reads. Data can be changed by other transactions between individual statements within the current transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.


The behavior of READ COMMITTED depends on the setting of the READ_COMMITTED_SNAPSHOT database option:


If READ_COMMITTED_SNAPSHOT is set to OFF (the default), the Database Engine uses shared locks to prevent other transactions from modifying rows while the current transaction is running a read operation. The shared locks also block the statement from reading rows modified by other transactions until the other transaction is completed. The shared locks are released when the statement completes.


If READ_COMMITTED_SNAPSHOT is set to ON, the Database Engine uses row versioning to present each statement with a transactionally consistent snapshot of the data as it existed at the start of the statement. Locks are not used to protect the data from updates by other transactions.


When the READ_COMMITTED_SNAPSHOT database option is ON, you can use the READCOMMITTEDLOCK table hint to request shared locking instead of row versioning for individual statements in transactions running at the READ_COMMITTED isolation level.

Note:
When you set the READ_COMMITTED_SNAPSHOT option, only the connection executing the ALTER DATABASE command is allowed in the database. There must be no other open connection in the database until ALTER DATABASE is complete. The database does not have to be in single-user mode.

И клавиатура- Клава... и монитор-Моня... и процессор - Проша... да и ВВП-Вова... :-))

Igor KorolyovВ последних версиях Oracle и MS SQL довольно сильно сходятся - т.е.
поперенимали они друг у друга многое...
Но вот MSSQL у Oracle гораздо больше. И "исторически" для меня сложилось - видел хорошие приложения только под Oracle. Но не хочу сталкивать лбами Oracle-MSSQL. Эта тема другого форума.
Igor KorolyovТЗ это на 99% фикция - т.е. там конечно написано что должна делать
программа - но в настолько "общих чертах" - что говорить об этом серьёзно не
приходится - да и зачастую к моменту завершения программы она
"переквалифицируется" в совсем другую сущность, нежели задумывалось в момент подготовки этого самого ТЗ...
Чем хуже ТЗ - тем хуже сдача проекта. Если в ТЗ не описано конкретно, что должно делать приложение, заказчик будет каждый день придумывать что-то новое: "вот здесь не так, здесь доделайте, здесь шрифт не тот, переделайте, здесь не автоматизирован вот эта задача..." не дай бог в это время меняется законодательство (надо сразу заключать доп.договор - а у вас фиктивное ТЗ на руку заказчику, прикрыться нечем). И договор ЗАТЯГИВАЕТСЯ. Это на руку только заказчику.
Юридические отношения не должны переходить в товарищеские. "Товарищи" уходят и приходят.
Igor KorolyovНо это не решает проблем - ибо уже который год я наблюдаю постоянное
"общение" пользователей с разработчиками или сопровожденцами - конечно не
всегда по тем самым вопросам, которые подробно описаны в руководстве - но
достаточно часто. Часто беспокоят из за своего-же дуболомства - навводят
чёрт-те чего, потом ничего не сходится - и как результат "программа у вас
плохая" - на зеркало пеняют
И я тоже хожу 4-ый год, обслуживаю, дабы не потерять марку.
Тоже, бывает, навводят чёрт-те чего, потом ничего не сходится .
Так во избежание таких ситуаций и нужна Инструкция к действию, как можно больше ограничений на этапе ввода информации. Если надо вводить "Мэ/Жо", то пусть других вариантов и не будет. :-))