Re: автоматизированный переход на 2.5
Dmitri Kuzmenko wrote: нет, подрихтовать код для конкретного случая, один раз. p.s. за бабло? Я ЛОА ето писал уже, и бабло предлагал (не конкретную сумму, а ждал ответа за сколько такое можно сделать), но ... наверно занят человек, понемаю, необижаюсь :( :( :( Regards Janex P.S. Если комуто интересно, то сумму можем обсудить, можете писать прямо на janis(точка)briska(собака)MedicusData(точка)lv
Re: автоматизированный переход на 2.5
Hello, Dmitry! Dmitry Yemanov wrote: вопрос не совсем к тебе - а что, нельзя переписать бэкап чтобы идентификаторы кодировки при ресторе менял? принудительно. Зашить в него знание ID-шников яффила? Нафиг. нет, подрихтовать код для конкретного случая, один раз. p.s. за бабло? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: автоматизированный переход на 2.5
Dmitri Kuzmenko ... Hello, Dmitry! Dmitry Yemanov wrote: вопрос не совсем к тебе - а что, нельзя переписать бэкап чтобы идентификаторы кодировки при ресторе менял? принудительно. Зашить в него знание ID-шников яффила? Нафиг. нет, подрихтовать код для конкретного случая, один раз. IMHO, лучше добавить дятловому гбаку ключ для создания правильных бекапов. -- Хосрун Влад p.s. за бабло? PS дык PPS не я :)
Re: автоматизированный переход на 2.5
Vlad Khorsun wrote: IMHO, лучше добавить дятловому гбаку ключ для создания правильных бекапов. найти бы его исходники ;) Да хотя бы его самого найти. p.s. за бабло? PS дык PPS не я :) тогда надо искать кто бы сделал. Мне кажется не сильно уж и сложно. Вообщем, Янекс, ищи доборовольца.
Re: автоматизированный переход на 2.5
Dmitri Kuzmenko wrote: нет, подрихтовать код для конкретного случая, один раз. p.s. за бабло? Таких конкретных случаев будет по числу клиентов. Янексу чарсет-ид мешает, кому-то еще BLR для встроенных функций, другому - еще что-либо. В сад, в общем :-) -- Дмитрий Еманов
Re: автоматизированный переход на 2.5
Dmitry Yemanov wrote: Таких конкретных случаев будет по числу клиентов. Янексу чарсет-ид мешает, кому-то еще BLR для встроенных функций, другому - еще что-либо. В сад, в общем :-) ну почему в сад. Ему надо приватно сделать, скомпилить, забэкапить и забыть про проблему.
Re: автоматизированный переход на 2.5
Kochmin Alexandr ... Vlad Khorsun wrote: IMHO, лучше добавить дятловому гбаку ключ для создания правильных бекапов. найти бы его исходники ;) Да хотя бы его самого найти. Это не проблема p.s. за бабло? PS дык PPS не я :) тогда надо искать кто бы сделал. Мне кажется не сильно уж и сложно. Вообщем, Янекс, ищи доборовольца. А это - проблема. А может и нет :) -- Хорсун Влад
Re: автоматизированный переход на 2.5
вот что значит конкуренция Извините за оффтоп, но в продолжении к разговору, обозначились новые тарифы по моему провайдеру, кому интересно http://www.icn.od.ua/servicesnew.html курс - 8 Знаковый момент - пакета 1 мегабит уже нет, минимально с 2 мегабит.
Re: автоматизированный переход на 2.5
Таких конкретных случаев будет по числу клиентов. Янексу чарсет-ид мешает, кому-то еще BLR для встроенных функций, другому - еще что-либо. В сад, в общем :-) ну почему в сад. Ему надо приватно сделать, скомпилить, забэкапить и забыть про проблему. Ну да. А страдать тогда по чему? Неее, это не наш метод :-) Коваленко Дмитрий.
Re: автоматизированный переход на 2.5
Andrei wrote: Если имеем базу на Yaffil, то для ее перевода на 2.5, достаточно ли будет выполнить следующую последовательность действий: ... Мдаа ... не тоже ето в переди, думаю в етом году приступить :( Немношко поексперементировал всякие варианты. У меня один клиент 24/7 и если более часа выганять их из базы, то ето плохо, база ~ 2.5 Gb. Для себя нашёл такое решение, наверно и при неи останусь, если некто чтото лучше нопосоветует: 1. Разделяем базу на 2 скрипта, в первом только голые таблицы, без индексов и ключеи 2. Из первого скрипта делам базу на FB 3. С FBCopy переганяем данные из Yaffil-a а FB 4. Накатываем второи скрипт. Шас точно непомню, но 2.5 гига + индекси перелились гдето меньше чем за час. В принципе был приятно удевлён насколько быстро FBCopy переливает данные ... Regards Janex
Re: автоматизированный переход на 2.5
Шас точно непомню, но 2.5 гига + индекси перелились гдето меньше чем за час. В принципе был приятно удевлён насколько быстро FBCopy переливает данные ... Это медленно ! Посмотри с какой скоростью это сделает gbak... Если речь о 2.5, то, повторюсь, - он сам может вытянуть данные из дятловой БД. Иначе - см.выше, я уже писал -- Хорсун Влад
Re: автоматизированный переход на 2.5
Khorsun Vlad wrote: Шас точно непомню, но 2.5 гига + индекси перелились гдето меньше чем за час. В принципе был приятно удевлён насколько быстро FBCopy переливает данные ... Это медленно ! Посмотри с какой скоростью это сделает gbak... Если речь о 2.5, то, повторюсь, - он сам может вытянуть данные из дятловой БД. Иначе - см.выше, я уже писал -- Хорсун Влад Да но у меня там кодировка 1257 и по краинеи мере FB 2.1 ето непереваривает :( :( :( Даавно уже про ето плакал :) Сомневаюсь что y 2.5 чтото менялось нашёт етого, но если менялось/будет менятся, был бы страно рад :) Regards Janex
Re: автоматизированный переход на 2.5
Да но у меня там кодировка 1257 и по краинеи мере FB 2.1 ето непереваривает :( :( :( Даавно уже про ето плакал :) Сомневаюсь что y 2.5 чтото менялось нашёт етого, но если менялось/будет менятся, был бы страно рад :) Я вот тебя сколько помню - ты перманентно плачешь по поводу вот этого клиента :-) Каких-то вшивых ~3 гига Насчет непереваривает - там что WIN1257 другая? Я не про идентификаторы, а саму кодовую таблицу. Коваленко Дмитрий.
Re: автоматизированный переход на 2.5
Да но у меня там кодировка 1257 и по краинеи мере FB 2.1 ето непереваривает :( :( :( Даавно уже про ето плакал :) Сомневаюсь что y 2.5 чтото менялось нашёт етого, но если менялось/будет менятся, был бы страно рад :) Если сможешь запустить одновременно Ya и FB 2.5, то всё получится. Например - Yaffil работает как и работал, а FB 2.5 embedded создаёт новую БД, коннектится к Yaffil'у и импортирует данные. -- Хорсун Влад
Re: автоматизированный переход на 2.5
Kovalenko Dmitry wrote: Насчет непереваривает - там что WIN1257 другая? Я не про идентификаторы, а саму кодовую таблицу. ID там другие, вот и вся проблема. Соотв-но, бекап-рестор не канает. -- Дмитрий Еманов
Re: автоматизированный переход на 2.5
Насчет непереваривает - там что WIN1257 другая? Я не про идентификаторы, а саму кодовую таблицу. ID там другие, вот и вся проблема. Соотв-но, бекап-рестор не канает. Какой кашмар. Гарантировано можно еще лет десять страдать :-) Коваленко Дмитрий.
Re: автоматизированный переход на 2.5
Khorsun Vlad wrote: Если сможешь запустить одновременно Ya и FB 2.5, то всё получится. Например - Yaffil работает как и работал, а FB 2.5 embedded создаёт новую БД, коннектится к Yaffil'у и импортирует данные. Ну ето ясно, так то и будем делать, только как уже выше писали, ID кодовои страници другои, изза чего FB невсасывает бекап Yaфила :( Regards Janex
Re: автоматизированный переход на 2.5
Kovalenko Dmitry wrote: Насчет непереваривает - там что WIN1257 другая? Я не про идентификаторы, а саму кодовую таблицу. ID там другие, вот и вся проблема. Соотв-но, бекап-рестор не канает. Какой кашмар. Гарантировано можно еще лет десять страдать :-) Коваленко Дмитрий. Ну я уже смерился :) Regards Janex
Re: автоматизированный переход на 2.5
Intertelecom CDMA 45 грн в месяц в пакете 700 mb трафика. Дмитрий туда же PeopleNet club 0.03 грн. ($0.00375) за мегабайт без абонплаты.
Re: автоматизированный переход на 2.5
Ты не сравнивай центральные города с региональными. Отъедь от Одессы на 100км, и посмотри, почем и какой там интернет. 100 км от Одессы это Николаев ;-) Сомневаюсь что сильно дороже будет. Но в целом понятно, я ж и писал что конкуренция превыше всего. Для негорода у нас три оператора, позиционирующих себя как 2.5G - 3G intertelecom people.net mts connect Фильмы конечно не покачаешь, но для почты и серфинга - самое то.
Re: автоматизированный переход на 2.5
Hello, Dmitry Dmitry Yemanov wrote: Насчет непереваривает - там что WIN1257 другая? Я не про идентификаторы, а саму кодовую таблицу. ID там другие, вот и вся проблема. Соотв-но, бекап-рестор не канает. вопрос не совсем к тебе - а что, нельзя переписать бэкап чтобы идентификаторы кодировки при ресторе менял? принудительно. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: автоматизированный переход на 2.5
Dmitri Kuzmenko wrote: вопрос не совсем к тебе - а что, нельзя переписать бэкап чтобы идентификаторы кодировки при ресторе менял? принудительно. Зашить в него знание ID-шников яффила? Нафиг. -- Дмитрий Еманов
Re: автоматизированный переход на 2.5
Я думаю, что ты стал заложником своих иллюзий или обыкновенных незнаний про работу других серверов. согласен. возможно, я не прав.
Re: автоматизированный переход на 2.5
Hello, Andrei! Andrei wrote: Вот по этому большинство проектов выбирают PostgreSQL. Из-за совместимости между версиями. Вот по этому 1С выбрала постгресс. А если бы взяли ФБ и установили его на 10 000 предприятий, вы бы им тоже порекомендовали через скрипт? не надо истерик. Я предупреждал о необходимости перехода с Ya на FB в 2003 году, 5 лет назад. За пять лет можно было подумать? И 1C выбрала pgsql не поэтому, они вообще создали свой клон. так что, рекомендую осмотреть пристальным взглядом текущие версии вашей БД, и отработать вариант перехода. А не впадать в панику, изучая теорию. Можно же проблемным объектам сначала сделать alter на ya, чтобы закомментировать не тот blr, а уже потом рекомпилировать объект по новому на 2.5. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: автоматизированный переход на 2.5
Hello, Rust! RUST wrote: конечно. удаленный доступ в Беларуси. вы хоть цены наши знаете на интернет? ADSL на скорости 1024/512 Кбит, анлим по трафику, стоит около 400 USD + 18% НДС в месяц. В Одессе: анлим 1024 стоит $10 по текущему курсу анлим 5Mb (акционный) стоит $12 есть 5Mb за $8 (первые 75Gb) потом скорость 1024 вот что значит конкуренция В Калуге (200км от Москвы) недавно безлимит 128кбит за 900 руб повысили до 256кбит. Ты не сравнивай центральные города с региональными. Отъедь от Одессы на 100км, и посмотри, почем и какой там интернет. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: автоматизированный переход на 2.5
т.е. : 1) выгрузить структуру БД в скрипт и создать на основе него новую базу? 2) выгрузить данные в скрипт и залить их на новую базу? тогда следующие вопросы: 1) кто нибудь делал это на базах по 20 Гб? 2) какие есть инструментальные средства для создания скриптов структуры и данных в автоматическом режиме? и еще, я понимаю, что хочется сострить. про морг, ах как весело. а если клиентская база более 2000? А если есть клиент у которого 260 офисов в каждом из которых свой сервер с базой? Что делать теперь? Ездить к каждому и вручную качать через скрипт? Вот по этому большинство проектов выбирают PostgreSQL. Из-за совместимости между версиями. Вот по этому 1С выбрала постгресс. А если бы взяли ФБ и установили его на 10 000 предприятий, вы бы им тоже порекомендовали через скрипт? И последний вопрос: в чем состоит непреодолимая проблема взять при разбэкапе текст той-же хранимой процедуры и перекомпилировать его?
Re: автоматизированный переход на 2.5
On 17 янв, 12:22, Andrei gs1...@gmail.com wrote: т.е. : 1) выгрузить структуру БД в скрипт и создать на основе него новую базу? 2) выгрузить данные в скрипт и залить их на новую базу? тогда следующие вопросы: 1) кто нибудь делал это на базах по 20 Гб? 2) какие есть инструментальные средства для создания скриптов структуры и данных в автоматическом режиме? 1) БД 15 Гб, есть таблицы по 3 и 23 млн. записей 2) Разработка БД сразу велась в виде скриптов и одновременно создавались командные файлы (.bat) для генерации различных вариантов БД 3) Экспорт в скрипты писался сразу как необходимая функция (решение в лоб писалось быстро). При этом функция писалась для экспорта любого фрагмента БД без использования сурогатных ключей. И этим во многом проверялась структура БД. Кроме переноса БД в другую версию, эти фукции использовались для переноса данных при изменениях структуры БД. Результат: Для простых таблиц (при отсутствии индексов) заказчка данных тормозилась только сетевым интерфейсом (100 Мб не хватало) Для таблиц с большим набором индексов происходило существенное замедление по мере наполнения индекса - пересчет индекса возвращал скорость загрузки на первоначальный уровень. В одной транзакции закачивалось от 1 до 10 записей. В принципе ничего страшного нет - если отработан командный файл, то вероятность ошибок минимальна. IBExpert (и EMS) экспортируют в скрипты, но только БД как единого целого. И иногда возникали проблемы.
Re: автоматизированный переход на 2.5
и еще, я понимаю, что хочется сострить. про морг, ах как весело. Ты 2.5 чем-нибуть интенсивным и долгоиграющим тестил? --- Коваленко Дмитрий.
Re: автоматизированный переход на 2.5
On Jan 17, 11:22 am, Andrei gs1...@gmail.com wrote: и еще, я понимаю, что хочется сострить. про морг, ах как весело. а если клиентская база более 2000? А если есть клиент у которого 260 офисов в каждом из которых свой сервер с базой? Что делать теперь? Ездить к каждому и Для таких клиентов и масштабов обычно принято иметь удаленный доступ всюду, чтобы никуда не ездить. Либо персонал с машинами, который поедет и все сделает самостоятельно. И заодно собственный набор инструментальных средств, типа автоапдейтеров. У нас так уже три версии FB сменилось, в том числе и силами самих заказчиков. Собственно говоря, не вижу никакой проблемы в том, чтобы выгрузить данные, создать базу заново из скриптов(я надеюсь, у вас исходники базы в виде пригодном для ее создания есть), и загрузить данные обратно (возможно, с временным выключением индексов).
Re: автоматизированный переход на 2.5
Andrei ... т.е. : 1) выгрузить структуру БД в скрипт и создать на основе него новую базу? 2) выгрузить данные в скрипт и залить их на новую базу? Зачем скрипт ? FB 2.5 может напрямую вытянуть данные из Yafill'а, если уж так делать. Я уже писал где-то другой способ : 1. Удалить все метаданные, кроме таблиц 2. Бекап\рестор 3. Накатить метаданные, кроме таблиц, из скрипта ... и еще, я понимаю, что хочется сострить. про морг, ах как весело. Кому хочется ? а если клиентская база более 2000? А если есть клиент у которого 260 офисов в каждом из которых свой сервер с базой? Что делать теперь? Ездить к каждому и вручную качать через скрипт? А сколько ты перевёл в FF от такой клиентской базы ? Вот по этому большинство проектов выбирают PostgreSQL. А ты пробовал на PG мигрировать БД с 7.х на 8.х ? А время засекал ? Расскажи - послушаем... Из-за совместимости между версиями. Между версиями кого-чего ? Кто есть Yaffil и кто есть FB ? Кто обещал полную совместимость ? Вот по этому 1С выбрала постгресс. А если бы взяли ФБ и установили его на 10 000 предприятий, вы бы им тоже порекомендовали через скрипт? И последний вопрос: в чем состоит непреодолимая проблема взять при разбэкапе текст той-же хранимой процедуры и перекомпилировать его? А ты уверен, что он в БД вообще есть ? А тебе 2.5 отказывала в ресторе, при переходе с FB, а не с *другой* СУБД ? -- Хорсун Влад PS заканчивай истерику... PPS до выхода 2.5, я уверен, ты решишь проблему :)
Re: автоматизированный переход на 2.5
Для таких клиентов и масштабов обычно принято иметь удаленный доступ всюду, чтобы никуда не ездить. конечно. удаленный доступ в Беларуси. вы хоть цены наши знаете на интернет? ADSL на скорости 1024/512 Кбит, анлим по трафику, стоит около 400 USD + 18% НДС в месяц. даже по крупным заводам ходим по полгода, убеждаем в необходимости связать например фирменную торговлю и основной офис VPN-ом.
Re: автоматизированный переход на 2.5
On Jan 17, 4:24 pm, Andrei gs1...@gmail.com wrote: Для таких клиентов и масштабов обычно принято иметь удаленный доступ всюду, чтобы никуда не ездить. конечно. удаленный доступ в Беларуси. вы хоть цены наши знаете на Я сам из Беларуси. У нас около 150 клиентов по всей стране с удаленным обслуживанием. интернет? ADSL на скорости 1024/512 Кбит, анлим по трафику, стоит около 400 USD + 18% НДС в месяц. даже по крупным заводам ходим по полгода, убеждаем в необходимости связать например фирменную торговлю и основной офис VPN-ом. У нас 64/64 анлимы у клиентов - для того чтобы залезть по RDP или новым сетевым протоколом от FB запросто хватает. И вообще можно свой сервер в ДЦ белтелекома поставить и по байфлаевскому гостевому соединению пускать на него. А VPN вообще копейки какие-то стоит, насколько я помню.
Re: автоматизированный переход на 2.5
конечно. удаленный доступ в Беларуси. вы хоть цены наши знаете на интернет? ADSL на скорости 1024/512 Кбит, анлим по трафику, стоит около 400 USD + 18% НДС в месяц. В Одессе: анлим 1024 стоит $10 по текущему курсу анлим 5Mb (акционный) стоит $12 есть 5Mb за $8 (первые 75Gb) потом скорость 1024 вот что значит конкуренция
Re: автоматизированный переход на 2.5
У нас 64/64 анлимы у клиентов - для того чтобы залезть по RDP или ну, если скорости 64 кбит/сек хватает, то тогда дейтвительно никаких проблем нет. а прижмет, так можно и модемом дозвониться :)
Re: автоматизированный переход на 2.5
On Jan 18, 12:19 am, Andrei gs1...@gmail.com wrote: У нас 64/64 анлимы у клиентов - для того чтобы залезть по RDP или ну, если скорости 64 кбит/сек хватает, то тогда дейтвительно никаких проблем нет. а прижмет, так можно и модемом дозвониться :) Ладно бы модемом, а то ведь бывает и по GPRS :) Вот в него уже ничего, кроме ssh и RDP, не пролезет.
Re: автоматизированный переход на 2.5
Andrei пишет: Если имеем базу на Yaffil, то для ее перевода на 2.5, достаточно ли будет выполнить следующую последовательность действий: 1) Подключаемся к базе Yaffil встроенным FB 2.5 2) Перекомпилируем все: а) процедуры, б) триггеры, в) вычисляемые поля, г) представления для того, чтобы подхватились новые встроенные функции BIN_AND, BIN_OR и т.п. вместо встроенных функций Yaffil, которые имеют другие коды в BLR 3) Бэкапим базу с помощью gbak от 2.5 4) Восстанавливаем базу с помощью gbak от 2.5 указав ключи fix_fss_data, fix_fss_metadata если база не десятки гигабайт, то может проще будет так сделать: 1. Воссоздать базу из скриптов под 2.5 с учетом изменений (главное структуру таблиц не менять) 2. Запустить яфил и фб2.5 (можно на одном сервер можно на разных, как тебе удобней) 3. с помощью IBPump перелить данные из старой базы в новую
Re: автоматизированный переход на 2.5
если база не десятки гигабайт, то может проще будет так сделать: 1) будут базы и более 1 Гб 2) самое главное хотелось бы полностью автоматизировать процесс, встроить его в инстолятор, так чтобы при установке новой версии программы сервер менялся и база конвертировалась.
Re[2]: автоматизированный переход на 2.5
Hello Andrei. если база не десятки гигабайт, то может проще будет так сделать: A 1) будут базы и более 1 Гб A 2) самое главное хотелось бы полностью автоматизировать процесс, A встроить его в A инстолятор, так чтобы при установке новой версии программы сервер A менялся A и база конвертировалась. IBPump может работать в пакетном режиме. Есть ещё вариант: выгнать всё в скрипт, исправить то что нужно прямо в скрипте (утилитой или скриптовым языком), а скрипт накатить уже в 2.5. -- Best regards, Jerry mailto:jer...@yandex.ru
Re: автоматизированный переход на 2.5
Andrei wrote: 2) Перекомпилируем все: а) процедуры, б) триггеры, в) вычисляемые поля, г) представления для того, чтобы подхватились новые встроенные функции BIN_AND, BIN_OR и т.п. вместо встроенных функций Yaffil, которые имеют другие коды в BLR Есть сомнения, что этот шаг пройдет. Ибо сначала будет читаться/парситься старый BLR и тут сервер скорее всего пошлет далеко в лес. -- Дмитрий Еманов
Re: автоматизированный переход на 2.5
Есть сомнения, что этот шаг пройдет. Ибо сначала будет читаться/парситься старый BLR и тут сервер скорее всего пошлет далеко в лес. а что делать в таком случае? как правильно проапгрейдить базу?
Re: автоматизированный переход на 2.5
Andrei wrote: а что делать в таком случае? как правильно проапгрейдить базу? Через скрипт. -- Дмитрий Еманов
