Меня все больше удивляют авторы СУБД PostgreSQL. На моих тестовых серверах и у клиентов установлена ее 11-я версия. Обычно я стараюсь себе на компьютер устанавливать последние версии программного обеспечения. Так же было и с PostgreSQL - когда возникла необходимость ее установить локально, я установил 12-ю версию. Залил дамп базы, запустил свою утилиту и получил ошибку "column pd.adsrc does not exist". Я сразу подумал, что при импорте дампа возникла ошибка и загрузил его снова. Но ошибка повторилась. Установил PostgreSQL на другой компьютер и получил "столбец pd.adsrc не существует".
Гугл быстро дал ответ на мою проблему. Оказалось, что в PostgreSQL 12-й версии из системной таблицы pg_catalog.pg_attrdef разработчики удалили поле "adsrc". Они просто решили, что это поле устаревшее и оно им не нужно... Вот разве так можно? Гора программного обеспечения, которую годами разрабатывали программисты по всему миру, перестанет корректно работать на новой версии СУБД. Может мне везло, но с подобной проблемой я не сталкивался ни у Oracle, ни у MS SQLServer. Например, недавно я узнал, что несколько почтовых сервисов, который я писал примерно 16-18 лет тому назад, успешно работают с базой данных на MS SQLServer 2019. Таким образом в моих глазах СУБД PostgreSQL получает очередной минус.
Все предлагаемые мне гуглом варианты решения этой проблемы были для pgAdmin. А что делать тем, у кого запросы не в скрипте, а в бинарнике? Первая моя мысль была добавить поле adsrc в таблицу pg_catalog.pg_attrdef. Но все же я решил, что это не выход. Правильно решать ее в своей программе. В используемой мной библиотеке для доступа к базам данных "PostgreSQL 12 is supported" только с версии 8.1. То есть для меня путь к 12-й версии PostgreSQL один - "достать кошелек" и обновить UniDac. Эта ситуация с PostgreSQL еще раз подтвердила, что использование open source продуктов, даже если не на прямую, а косвенно, но все равно приводит к лишним затратам.
Гугл быстро дал ответ на мою проблему. Оказалось, что в PostgreSQL 12-й версии из системной таблицы pg_catalog.pg_attrdef разработчики удалили поле "adsrc". Они просто решили, что это поле устаревшее и оно им не нужно... Вот разве так можно? Гора программного обеспечения, которую годами разрабатывали программисты по всему миру, перестанет корректно работать на новой версии СУБД. Может мне везло, но с подобной проблемой я не сталкивался ни у Oracle, ни у MS SQLServer. Например, недавно я узнал, что несколько почтовых сервисов, который я писал примерно 16-18 лет тому назад, успешно работают с базой данных на MS SQLServer 2019. Таким образом в моих глазах СУБД PostgreSQL получает очередной минус.
Все предлагаемые мне гуглом варианты решения этой проблемы были для pgAdmin. А что делать тем, у кого запросы не в скрипте, а в бинарнике? Первая моя мысль была добавить поле adsrc в таблицу pg_catalog.pg_attrdef. Но все же я решил, что это не выход. Правильно решать ее в своей программе. В используемой мной библиотеке для доступа к базам данных "PostgreSQL 12 is supported" только с версии 8.1. То есть для меня путь к 12-й версии PostgreSQL один - "достать кошелек" и обновить UniDac. Эта ситуация с PostgreSQL еще раз подтвердила, что использование open source продуктов, даже если не на прямую, а косвенно, но все равно приводит к лишним затратам.
Ну, что не встретился с подобным в других СУБД, то это просто повезло.
ОтветитьУдалитьКак раз подобная ситуация была с Oracle, когда они поменяли сигнатуру поля CLOB.
Пришлось обновлять библиотеку доступа (уж и не помню точное название).
Так что и с проприетарными продуктами от такой ситуации никто не защищен.
Немного запоздалый коммент оставлю:
ОтветитьУдалитьDevArt unidac оперативно поправили библиотеку.
У тех у кого она куплена все в исходниках, то правилось одной строчкой (если нужно могу для ветки 7.xx выслать правку), да и для всех она одинаковая.
К слову pd.adsrc deprecated был еще в версии postgresql версии 9
Так же обновился EMS manager.
Мне вот пришлось править скрипты в Sybase Power Designer (который не поддерживается) - это печально
@Анонимный
ОтветитьУдалитьТут одно из трех:
1. или в этот момент я пользовался другой СУБД - судьба меня кидала то на Oracle, то на SQLBase, то на MSSQL, то на FB, то на MySQL, то на SQLite и даже на DBF :)
2. или библиотека доступа не знала такой проблемы. До UniDac я пользовался SQLDirect и лично знал ее автора, поэтому найденные мной баги закрывались в течении пару часов. Хотя багов в SQLDirect почти не было - стабильный был проект
3. или в тот момент у меня не было CLOB'а в программе
@uranic
ОтветитьУдалитьУ тех, у кого UniDac куплена без сорцов - править то не чего :(
Devart может и подправили библиотеку оперативно, но у них "one year support and upgrades"... Вот раньше, когда трава была зеленее, библиотеки продавались не с обновлением на год, а с пожизненной гарантией :)
Я в Power Designer 6 правил скрипт для SQLBase. Тогда выпустили SQLBase 7 и пришлось самому допиливать.
А в PostgreSQL 12 у меня реально пока нужды нет. Вот если заказчики захотят его - они мне UniDac новый и купят :) или Devart мне за хвалебные упоминания в статьях его подарит... Посчитал - уже 4 статьи про UniDac, а еще несколько в голове, и если руки дойдут и не забуду - то напишу. Хотя, что это я размечтался? Времена щедрости разработчиков библиотек (те самые, когда трава была зеленее) давно закончились...
ОтветитьУдалитьБыло бы отлично, если бы сюда выложили патч для UniDAC
ОтветитьУдалить