Onizuka писав:Они все описаны на сайте FB сравнение 2.1 и 3.0
Так же лично упирался в стену библиотек медка при работе с базами больше 3Гб, нюансы разработчик знает.
От 3.0 выиграют все, Полтава-Енержи подтвердит, плюс так же уйдут текущие ограничения.
Перепрошую, але мене цікавили лише обмеження і несерйозність в контексті МЕДока.
Я не заперечую, що версія FB3.0 значно розширює можливості розробників, проте вони (розробники), навіть близько не підійшли до вичерпання можливостей версії 2.1. Для версій FB понад 1.5 розмір БД обмежується можливостями файлової системи, а до обмеження на розмір таблиці в 32ТБ навіть дуже великій компанії ще працювати і працювати.
Розробники вже місяць не можуть екранувати апостроф у верхньому фільтрі, то чи є в цьому вина СУБД?)
Розробники дали можливість налаштувати FB, проте досі не створили можливості змінити пароль підключення до серверу.
Наша корпоративна програма працює з FB2.0 і всі бухгалтери підтвердять, що працює вона в десятки разів швидше за МЕДок, хоча кількість активних підключень там 70 проти 5, а розмір БД 60ГБ проти 10ГБ у МЕДока.
Тому мені й цікаво, які такі обмеження FB2.1, крім прямоти рук розробників, заважають МЕДоку нормально працювати?!
Ivanhoe писав:Несерьезность заключается в том, что эти сервера распространяются по лицензии GNU General Public License и InterBase Public License, бесплатно, "безвоздмездно, то есть дадом", как говорила тетушка Сова в мультике про Винни Пуха.
Linux, Open/LibreOffice, Mozilla Firefox, Mozilla Thunderbird також розповсюджуються за подібними ліцензіями, проте це не заважає їм бути хорошими продуктами...
Ivanhoe писав:А если даром, то соответственно, никто никому ничего не обещает, - ни гарантий, ни нормальной гарантированной поддержки, ни ответственности за наши проблемы с этими серверами, несмотря на то, что этими серверами каким-то боком занимается ORACLE (MySQL) и Сообщество Firebird.
За 3 роки не було жодної проблеми з серверами FB, всі проблеми, які виникали, були пов'язані з кривизною софту, написаного для роботи з цими серверами.
Не хочете втратити дані - робіть резервні копії, це правило діє для всіх без винятку СУБД. До речі, у МЕДоків з цим виникали проблеми: то планувальник не працює як треба, то модуль зарплати не входив в РК, то РК створювалась криво.
Ivanhoe писав:И вам на таком нравится работать? Без каких-либо гарантий и ответственности? Тогда, как данные Медка составляют для предприятий, в нынешних условиях, пардон, офигеннейшую ценность.
Это как в том анекдоте: "…яка країна – такі й теракти". Взяли бесплатные СУБД, - не жалуйтесь потом, что что-то пошло не так... Да и жаловаться будет не на кого, и некому... Ну, разве что, написать письмо на деревню дедушке...
СУБД не винна в тому, що МЕДок може перезаписати дані, не включити їх в РК чи підсунути вірус у файл з оновленням.
До речі, на скільки реально, що колгосп ім. Петрика П'яточкина з далекого поліського села може дозволити собі Oracle чи MS SQL сервер, а навіть якщо назбирали всім селом, то чи будуть вони судитися з Oracle чи Microsoft з компенсацію збитків від втрати даних?! Чи можливо таким організаціям не потрібно існувати?!
Головна проблема не в СУБД, яку використовує МЕДок, а в тому, що на ринку немає достойної конкуренції, тому розробники дозволяють собі поводитись з клієнтами як забажають...
Також не панацея. Писав стосовно верхнього фільтру, то ні відповіді, ні результату. Аналогічна ситуація і з тим, що після кожного оновлення заходжу у реєстр первинних документів і відправляю розробникам помилку з фільтром. Зворотній зв'язок - 0-й...
