проблемы с пересечением границ

ELSIF TO CHAR(launch datetime, DD-MON-YY HH24:MI:SS) < TO CHAR(SYSDATE, DD-MON-YY HH24:MI:SS) THEN

использование в ключах -- проблемы при упорядочении ... ORDER BY claim no; -- claim no -- YY/nnnnn

Эта проблема касается не только экранно-ориентированных программ, и следует учитывать ее влияние на отчеты, пакетные программы и код, резидентный в базе данных. Отчеты не должны создавать слишком серьезную проблему, потому что они обьино не обновляют базу данных. Кроме того, если они показывают только двузначный год, пользователь, скорее всего, сможет истолковать его правильно в контексте отчета. Однако некоторые регулярно запускающиеся отчеты могут обновлять таблицу, в которой регистрируется последнее время запуска отчета, а оно наверняка будет включать поле даты. Кроме того, может оказаться, что столбец даты, помещенный из базы данных в поле отчета, не содержащее век, используется в условии последующего запроса. В отчетах следует также внимательно следить за тем, как осуществляется обработка параметров, которые являются датами.

В пакетных программах проблемы обычно возникают там, где значения столбцов типа DATA помещаются в символьные переменные без века, а затем записываются опять в столбцы типа DATA базы данных или используются в условиях SQL-предложений. Увеличить размер этих переменных на два символа и заменить маски YY на YYYY довольно просто.

Таким образом, вряд ли возможно избежать необходимости добывать старый прикладной код Oracle-систем и копаться в нем. Конечно, может быть, кто-то только этого и ждет, чтобы переписать массу этого кода (и модифицировать его, например, для применения ГПИ). Однако можно ли назвать разумным предложение переписать все существующие эксплуатируемые системы? К сожалению, у нас может не быть иного выбора, если мы не найдем весь исходный код.

Однако оставим пока вопрос о тотальном переписывании и посмотрим, как с наименьшими затратами вьшолнить поиск и исправление проблемных фрагментов кода.

Поиск начинается

Как найти сегменты кода, которые в новом столетии могут преподнести проблемы? Прежде всего, необходимо поместить файлы исходного кода в общий каталог (или создать отдельный каталог для файлов каждого типа). Затем требуется выбрать средство поиска. В ОС Unix есть богатый набор средств и утилит для поиска последовательностей символов в файлах (назовем лишь три из них - grep, sed и awk).

Что же мы ищем Сначала можно провести поиск всех строк, содержащих символы YY . Число ненужных совпадений можно сократить, если искать символы У только в строках, заключенных в одинарные кавычки (но при этом в некоторых комментариях может остаться У). Поиск всех экземпляров

YY , не входящих в строку YYYY , отсеет еще некоторое число ненужных совпадений, но не проскользнут ли в эту сеть нужные нам экземпляры? Можно расширить критерии поиска, включив экземпляр типа где

точка является метасимволом, обозначающим один любой символ. К сожалению, в SQL очень слабая типизация данных, и он позволяет конвертировать тип DATE в другие типы и наоборот, не задавая ни маску, ни конвертирующую функцию. Такие случаи найти простыми средствами поиска трудно.

В некоторых элементах кода могут возникать проблемы с датами, не имеющие связи с Oracle. Например, мы можем искать файл операционной системы по дате его создания. Часть нашего приложения может быть shell-скриптом Unix, в котором используется утилита date. В этом случае нам придется искать строки, содержащие последовательность %у . Таким образом, без глубокого понимания того, как работает приложение, мы никогда не найдем все эти вещи до тех пор, пока что-нибудь не начнет действовать неправильно. Это одна из причин, по которой тщательное тестирование имеет очень важное значение.

Если весь исходный код хранится в текстовых файлах, то в результате поиска будут найдены отдельные строки кода. Их можно проанализировать и некоторые проблемы устранить на месте. Поиск в двоичном файле вряд ли даст понятные результаты, но он все равно полезен, поскольку даст возможность установить, содержит ли SQL, встроенный в приложение, проблемные участки, о которых мы говорили. В конце поиска у нас будет список рисковых файлов исходного кода, требующих внимания, и мы получим общее представление о масштабе проблемы. После этого нужно лишь закатать рукава и устранить ее!

Устраняел1 проблему

К сожалению, каждый случай придется рассматривать отдельно. Мы не можем слепо заменить все экземпляры YY на RR. Сначала следует убедиться в том, правильно ли предположение, что любая дата, в которой год меньше 50, относится к двадцать первому веку. Конечно, нельзя заменять все экземпляры YY на YYYY, не проанализировав последствия от увеличения размеров для операций присваивания значений переменным или полям экранной формы. Если размер всех полей дат в экранной форме увеличится, то, возможно, придется полностью ее переделать.

Автолштизация процесса исправления кода

Если масштабы проблемы значительны, то следует подумать об автоматизации, особенно если в коде встречаются повторяющиеся структуры. Вновь упомянем утилиты Unix, подобные awk, идеально подходящие для этой цели. Если в операционной системе утилит для манипулирования строками нет, можно написать программу на 3GL (например, на С или Коболе), которая читает файл или набор файлов, выполняет ряд четко

определенных изменений и записывает файл. Вот некоторые правила, которых необходимо придерживаться, выполняя автоматизацию процесса исправления кода:

Перед началом работы сделайте резервную копию всего исходного кода.

Перед проведением операций над всем каталогом с исходным кодом протестируйте свои действия на одном файле.

В первую очередь займитесь повторяющимися проблемами, которые относительно легко устранить.

Периодически прогоняйте утилиту поиска, чтобы закрепить результаты.

Убедитесь в том, что любой автоматизированный метод предупреждает вас о потенциальных опасных последствиях и обязательно следуйте предупреждениям. Например, если в модуле Oracle Forms мы заменяем строчку

global.cur date ;= TO CHAR(SYSDATE, DD-MON-YY)

global.cur date := TO CHAR{SYSDATE, DD-MON-YYYY)

to должны проверить, где еще используется переменная global.curdate. Причем эта проверка не обязательно будет ограничена одной формой, и придется провести поиск и в других исходных файлах. Если обнаружится, что эта переменная используется, например, в таком присваивании:

:bl.cur date ;= :global.cur date

то необходимо посмотреть, как объявлена переменная :bl.cur date, и обеспечить, чтобы в нее можно было поместить более длинное значение. После этого мы должны проверить формы на предмет наличия ссылок на :bl.cur date и т.д.

Тестирование

Хорощая стратегия тестирования - ключ к успеху всего мероприятия. Если вам удастся убедиться, что все будет по высшему классу, то в новогоднюю ночь 1999 г. вы сможете спать (или веселиться) в полной уверенности, что ничего не произойдет. Протестируйте все модули, выявленные на этапе поиска, с использованием даты после 1 января 2000 г., чтобы посмотреть, что происходит, если код не изменять. Это даст возможность контролировать последствия проблемы и уверенность при повторном тестировании после исправления в том, что исправление было необходимым и эффективным.

Для каждого изменяемого исходного модуля выполните полное автономное тестирование. При этом следуйте плану автономного тестирования модуля (если он есть) и, конечно, добавьте к этому плану специальные тесты для проверки дат в 2000 г.