В моей практике был такой случай. Я перенес собственноручно написанную базу данных из "Access 2000" на "SQL-Server 2000", оставив, разумеется, весь пользовательский интерфейс без изменений. Однако, уже на второй день эксплуатации, на меня буквально обрушился целый шквал негодования пользователей. При ближайшем рассмотрении была выявлена следующая проблема: при сохранении записи в поле типа "Memo" вместо нормального текста на экран выдавались лишь какие-то бессмысленные квадратики. Негодованию пользователей не было предела, что и легко понятно: ведь в то время та база данных только вступила в эксплуатацию и по началу исполняла роль как хорошо структурированная, нормализованная база данных… для распечатки бумажных форм документов! :-) Идеологическим "ядром" в этой базе было, как нетрудно догадаться, как раз это самое поле Memo, на заполнение которого у пользователя уходила львиная доля рабочего времени. Когда же документ посылался на печатающее устройство, то пользователь, как на бумаге, так и на экране с ужасом видел вместо своего текста какие-то совершенно бессмысленные символы! Ввиду того, что текст, таким образом, сохранялся изначально, нечего даже было думать о неправильности установки принтера, системных шрифтов и т.п. (Хотя, объективности ради, следует заметить, что и такая мысль лихорадочно промелькнула. Я разработчик баз данных, а не системный программист, поэтому, наверное, так никогда и не доберусь до "внутренностей" Windows). Надо сказать, что эта ошибка и самого меня застала врасплох, ибо на моем компьютере, на котором была установлена ОС "Windows 2000", я, как ни старался, воспроизвести ее не смог. Именно это обстоятельство натолкнуло меня на мысль (как потом выяснилось - ошибочную), что все дело в операционной системе. К тому же, мою ошибочную гипотезу подтвердило то неожиданное совпадение, что у тех пользователей, на чьих компьютерах была установлена та же ОС, что и у меня, этой проблемы не возникало. Проблема проявлялась на компьютерах с ОС "Windows NT Workstation 4.0". Тем не менее, работа практически встала, и какие-то действия (причем немедленно), предпринимать было необходимо. Не найдя ничего лучшего (будет не лишним подчеркнуть, что это решение принималось под всеобщим психологическим давлением, когда нет времени даже на то, чтобы осмыслить суть происходящего), я кратко изъяснил суть проблемы системному администратору, и тот, не долго думая, просто переустановил ОС на "Windows 2000", после чего эта ошибка исчезла. Но только на этом компьютере. И все же, нутром я понимал, что суть проблемы не в операционной системе, хотя ее переустановка каким-то немыслимым способом помогла, благодаря чему я и получил более или менее вразумительное объяснение сути происходящего для руководства, тем самым, выиграв некоторое время, чтобы попытаться хоть как-то вникнуть в суть проблемы. Копаться в литературе было некогда, поиск на форуме в интернете также не дал результата (опять-таки по причине острой нехватки времени), и тогда я просто решил испробовать метод "научного тыка". Сославшись на технические обстоятельства, я "выгнал" всех пользователей из системы, и просто заменил тип данных этого поля с "ntext" на "text". Каково же было мое удивление, когда после этой нехитрой манипуляции эта ошибка исчезла! Навсегда.
Тип данных "ntext" предназначен для хранения больших текстов в стандарте UNICOD, и поэтому, по логике вещей, там не должно быть никаких проблем с символами из разных кодировок. (Собственно говоря, именно для этой цели он и был разработан). Поэтому, при импорте данных из Access в SQL-Server, поля типа "Memo" по умолчанию преобразовываются в тип "ntext". Однако, на практике, произошло как раз наоборот и при возврате к старому доброму "text" проблема исчезла. Можно только констатировать, что подобные ошибки относятся к недоработкам СУБД. Вдвойне обидно, что ошибка проявляется далеко не всегда и не везде. Нужно глубже изучать природу хранения данных! :-)