forum.clarionlife.net

gopstop2007 писал(а):насчет native с mysql, нам не повезло

Нам с FB тоже не повезло. С Postgres тоже не повезло. Повезло только с SQLite, да и то не особо актуально. Принципиальное нежелание конторы связываться с бесплатными серверами? Или на американском рынке эти продукты не актуальны?

gopstop2007 писал(а):

PavelNK писал(а):...Мораль: отказаться от прокладки.

насчет native с mysql, нам не повезло

kreator писал(а):

gopstop2007 писал(а):насчет native с mysql, нам не повезло

Нам с FB тоже не повезло. С Postgres тоже не повезло. Повезло только с SQLite, да и то не особо актуально. Принципиальное нежелание конторы связываться с бесплатными серверами? Или на американском рынке эти продукты не актуальны?

Почему не повезло, говоря про прокладку, я имел ввиду Клашину прокладку. Через ODBC я пробовал работать и с тем, и с другим - отлично быстро работает

PavelNK писал(а):Через ODBC я пробовал работать и с тем, и с другим - отлично быстро работает

Ну, слово "отлично" я бы не стал употреблять .

Таблицы Mysql создаются в С10 автоматом, но как в этот "автомат" впихнуть еще и AUTO_INCREMENT на стороне сервера?
СейчасНужно

gopstop2007 писал(а):Таблицы Mysql создаются в С10 автоматом, но как в этот "автомат" впихнуть еще и AUTO_INCREMENT на стороне сервера?

Кстати, уже обсуждали это. Не нужно ничего создавать "автоматом". Какая необходимость в этом? На крайний случай можно прогонять скрипты через prop:SQL.

kreator писал(а): Кстати, уже обсуждали это. Не нужно ничего создавать "автоматом". Какая необходимость в этом? На крайний случай можно прогонять скрипты через prop:SQL.

Необходимости, когда только одна-две программы в этом нет, но если ставишь намного больше раз и периодически обновляешь(дополняешь) структуру БД, отслеживать изменения еще и в скриптах, лишний геморрой.

gopstop2007 писал(а):Необходимости, когда только одна-две программы в этом нет, но если ставишь намного больше раз и периодически обновляешь(дополняешь) структуру БД, отслеживать изменения еще и в скриптах, лишний геморрой.

Всё равно неправильно это. Маленький пример. В словаре у таблиц индексы, по которым строятся броузы, должны быть уникальными. Не факт, что в базе должно быть то же самое. Я, например, использую много "виртуальных" индексов, просто для сортировки. А количество индексов влияет на скорость работы БД при операциях добавления, изменения... Зачем их создавать автоматически? И потом, что делать с триггерами, хранимками?

kreator писал(а):В словаре у таблиц индексы, по которым строятся броузы, должны быть уникальными. Не факт, что в базе должно быть то же самое. Я, например, использую много "виртуальных" индексов, просто для сортировки. А количество индексов влияет на скорость работы БД при операциях добавления, изменения... Зачем их создавать автоматически? И потом, что делать с триггерами, хранимками?

Тут не поспоришь , кстати как Вы делаете, через внешний файл скрипт или в "теле" программы прописываете?

У нас внешний файл

Мы делаем сразу в Базе скриптом.

"Подниму" тему - есть ли возможность работать с MySql через ODBC, НО без установки на клиентском компе самого ODBC-драйвера?
Ну, или другой способ работы с MySql через стандартные шаблоны Клариона без необходимости установки на клиентском компе каких либо дополнительных драйверов?

По моему инсталлировать придется по любому, если не натив.
Может ADO поможет, было уже https://forum.clarionlife.net/viewtopic ... 508#p25508

Олег писал(а): 06 Октябрь 2017, 4:46 Подниму" тему - есть ли возможность работать с MySql через ODBC, НО без установки на клиентском компе самого ODBC-драйвера?
Ну, или другой способ работы с MySql через стандартные шаблоны Клариона без необходимости установки на клиентском компе каких либо дополнительных драйверов?

У клиента запрет на установку драйверов ODBC?

По поводу ADO - нет особого желания переводить уже написанное приложение с шаблонов на совершенно другие рельсы.

Что до "запрета на установку драйверов" - нет, такого запрета нет. Просто предполагается большой "зоопарк" версий Винды на клиентских компах, совершенно неизвестное "окружение" из разного ПО, абсолютные "чайники" за компами в лице женщин среднего возраста, "приходящие админы" сомнительной квалификации и полное мое нежелание тратить свое время на поездки к клиентам с последующим "копанием" в их компах! Самое неприятное - госструктуры с полным запретом какого либо удаленного администрирования!

К тому же, в последнее время меня "разбаловали" питоновские скрипты, которые не требуют для своей работы практически с любыми БД никаких дополнительных настроек на клиентских компах.

тогда может в тихую поставить?
https://dev.mysql.com/doc/connector-odb ... s-dll.html
и еще перед установкой в реестре проверить наличие ODBC