Найден 61 результат

JayDi
Пт 10 сен 2021 07:44
Форум: dbForge for MySQL
Тема: Куда пропала русская версия dbForge for MySQL?
Ответы: 4
Просмотры: 4555

Re: Куда пропала русская версия dbForge for MySQL?

В техподдержки сказали, что бесплатной русской версии больше не будет в связи с ее бесполезностью.

Цитата: "Русскоязычная редакция утратила свою популярность и перестала приносить должный эффект и, соответственно, выполнять поставленные перед ней бизнес цели. Время, затраченое на разработку, оказалось несоизмеримым с результатами и получаемым фидбэком по продукту."
JayDi
Пн 06 сен 2021 14:43
Форум: dbForge for MySQL
Тема: Куда пропала русская версия dbForge for MySQL?
Ответы: 4
Просмотры: 4555

Куда пропала русская версия dbForge for MySQL?

Раньше до версии 8 включительно была полнофункциональная версия со всеми возможностями. Специально для русскоязычных пользователей. Бесплатная.

Сейчас же на сайте нет ссылок для ее скачивания или упоминаний. В таблице с редакциями есть некая express (ака триал) -- но у нее совсем всё урезано по функционалу.

Или ее все-таки как-то можно скачать как раньше?
JayDi
Сб 05 мар 2016 01:41
Форум: Universal Data Access Components
Тема: UniDac 6.2.8 - ошибка integeer overflow с SQLMonitor
Ответы: 1
Просмотры: 3693

UniDac 6.2.8 - ошибка integeer overflow с SQLMonitor

UniDac 6.2.8, XE6, в настройках проекта включена проверка check overflow.

Если у подключения указан SQLMonitor, то при выполнении запросов из датасета будет выскакивать ошибка о переполнении Integer overflow.

Ошибка появляется в вашей собственной реализации функции BobJenkinsHash из модуля CRFunctions. Стандартная реализация из System.Generics.Defaults работает корректно.

Пример нерабочего кода:

Код: Выделить всё

BobJenkinsHash(
  '05A0F3B0UniQuery_Items'[1], 
  Length('05A0F3B0UniQuery_Items') * SizeOf('05A0F3B0UniQuery_Items'[1]), 
  0
);
JayDi
Пт 18 сен 2015 18:16
Форум: dbForge for MySQL
Тема: Баги 6 версии
Ответы: 93
Просмотры: 78574

Re: Баги 6 версии

Еще одна ошибка в версии 6.3.358

Если в редакторе кода навести курсор мышки над любым объектом или командой -- появится всплывающая подсказка. НО если навести курсор и сразу после этого (не дожидаясь появления подсказки) переключиться на другое окно, например, через <ALT+TAB>, произойдет ОШИБКА -- подсказка "повиснет" и будет отрисовываться на переднем плане всегда, вне зависимости от того, в каком приложении мы работаем.

Пример:
Изображение
JayDi
Вс 13 сен 2015 20:08
Форум: dbForge for MySQL
Тема: Баги 6 версии
Ответы: 93
Просмотры: 78574

Re: Баги 6 версии

Версия 6.3.358

Ошибка с "неработающим" профилировщиком.

Режим профилирования не переключается, если фокус (курсор) стоит в любом месте программы, кроме редактора кода.

Шаги:
1. Открыть новое окно с запросом и ввести туда какой-нибудь код;
2. Нажать кнопку выполнить и в результатах запроса поставить фокус на какую-либо строку;
3. Нажать на кнопку "режим профилирования". Она станет активна;
4. Сразу после этого нажать на кнопку "выполнить". ОШИБКА. Вместо режима профилирования будет выполнен обычный запрос;
5. Меняем фокус на редактор кода и снова нажимаем "выполнить". Теперь корректно -- показаны результаты профилировщика.
JayDi
Вс 19 июл 2015 19:05
Форум: Universal Data Access Components
Тема: Появление AV, если в подключении есть настройки для другой базы
Ответы: 1
Просмотры: 3435

Появление AV, если в подключении есть настройки для другой базы

Версия UniDAC 6.1.5

Если в настройках подключения (TUniConnection) находятся специфичные опции из разных баз данных, то ваш код пытается применить их все, даже те из них, которые являются мусорными и относятся к другому типу базы. В результате появляется Access Violation, т.к. соответствующие юниты с провайдерами не были добавлены за ненадобностью.

Код: Выделить всё

Error reading UniConnection.SpecificOptions.Strings: MySQL provider is not registered. You should add the MySQLUniProvider unit to the uses clause of any unit in your project or place the TMySQLUniProvider component on the form.

Код: Выделить всё

MySQL provider is not registered. You should add the MySQLUniProvider unit to the uses clause of any unit in your project or place the TMySQLUniProvider component on the form.
Пример:

Подключение использует SQLite базу данных, но в самом компоненте когда-то был MySQL и часть настроек с тех времен сохранилось:

Код: Выделить всё

    SpecificOptions.Strings = (
      'MySQL.UseUnicode=True'
      'MySQL.ConnectionTimeout=500'
      'SQLite.UseUnicode=True'
      'SQLite.BusyTimeout=10000')
В результате при запуске приложения компоненты читают эти настройки и пытаются применить к MySQL, который на самом деле даже не используется, вызывая тем самым AV.

Приходится вручную из dfm-файла удалять "мусорные" настройки, чтобы заработало.
JayDi
Вт 06 янв 2015 16:23
Форум: Universal Data Access Components
Тема: Проблемы с производительностью процедур в MySQL
Ответы: 9
Просмотры: 16645

Re: Проблемы с производительностью процедур в MySQL

Забавно. Только сейчас обратил внимание. В новом коде обращение к INFORMATION_SCHEMA.ROUTINES используется только для того, чтобы узнать -- процедура это или функция. А далее вызывается код "SHOW CREATE PROCEDURE" или "SHOW CREATE FUNCTION".

Но в действительно, SHOW CREATE -- это чуть ли не аналог для обращения к всё той же mysql.proc :)
JayDi
Вт 06 янв 2015 16:09
Форум: Universal Data Access Components
Тема: Проблемы с производительностью процедур в MySQL
Ответы: 9
Просмотры: 16645

Re: Проблемы с производительностью процедур в MySQL

Dimon писал(а):Мы исследовали производительность доступа к таблицам mysql.proc и INFORMATION_SCHEMA.ROUTINES и не обнаружили значительной разницы во времени доступа даже для серверов с большим количеством баз и процедур. К тому же за более чем 7 лет использования данной функциональности вы первый пользователь, у кого воспроизводится описанная вами проблема.
Пожалуйста, укажите, какое конкретно время занимает доступ на вашем сервере к таблице mysql.proc и к INFORMATION_SCHEMA.ROUTINES.
То, что никто не жалуется -- не значит, что проблем нет. Дело в том, что использование процедур в MySQL -- очень редкое явление. А использование профайлеров - еще реже. С этой проблемой столкнулся 3 года назад и создал соответствующую тему. Проблема была решена в одном из обновлений. Но потом опять появилась.

Выше есть скриншоты AQTime с реальными замерами (см. строчки с цифрами слева: 10 -- 10 раз выполнился код, 539 -- на все 10 выполнений потрачено 539 мс времени).

Там же выше есть планы запроса для mysql.proc и для INFORMATION_SCHEMA.ROUTINES, где видно, что первый вариант использует индекс, а второй -- считывает все данные.

С тех пор ничего кардинально не изменилось.

Вот сегодняшний пример с тестового сервера (виртуальная линукс-машина с установленной MySQL (5.0.67), 1666 процедур во всех базах):

Код: Выделить всё

//время выполнения: 0,001 сек
SELECT type, returns, param_list FROM mysql.proc WHERE (name = 'm_orders_return_stages') AND (db = 'print_v29')

Код: Выделить всё

//время выполнения: 0,046 сек
SELECT ROUTINE_TYPE FROM INFORMATION_SCHEMA.ROUTINES WHERE (ROUTINE_NAME = 'm_orders_return_stages') AND  (ROUTINE_SCHEMA = 'print_v29')
Как видно, код выполняется в 46 раз медленнее.

На рабочем сервере (5.6.21-log) с 878 процедурами во всех базах результат аналогичный.

Как это влияет не реальную производительность -- можно увидеть выше на скриншотах в начале темы.
JayDi
Чт 09 окт 2014 11:18
Форум: Universal Data Access Components
Тема: Проблемы с производительностью процедур в MySQL
Ответы: 9
Просмотры: 16645

Re: Проблемы с производительностью процедур в MySQL

Грусть-печаль. В новых версиях UniDAC (возможно, начиная с пятой версии) "системные" запросы для получения информации о процедурах изменили с таблицы mysql.proc на INFORMATION_SCHEMA.ROUTINES -- которая вообще не является таблицей и не имеет никаких индексов.

В результате производительность запросов с вызовом процедур опять катастрофически упала (особенно заметно, если на сервере куча баз и процедур). Падение производительности -- в десятки раз (см. первый пост со скриншотами).

Посмотрел код в MyClassesUni.TMySQLCommand.GetSPParams, там стоит интересное условие вида:

Код: Выделить всё

  if ((FConnection.FServerPrimaryVer = 5) and (FConnection.FServerMinorVer = 0) and
    (FConnection.FServerReleaseVer < 4)) or FConnection.FEmbedded
  then
    _GetSPParams(IsFunc, ParamList, ReturnParam)
  else
    with GetParamBlock(GetCreateSQL) do begin
      ParamList := Params;
      ReturnParam := Returns;
    end;
Вот и получается, что _GetSPParams -- нормальный запрос к mysql.proc не вызывается. Зато запрашивается GetCreateSQL к проблемной INFORMATION_SCHEMA.

P.S. Я понимаю, что к INFORMATION_SCHEMA доступ есть по умолчанию у всех, а к mysql.proc надо отдельно настраивать. Но может все же можно добавить хотя бы дополнительную опцию типа "fast_routine_prepare" или т.п. аналог -- который бы включал старое поведение для сервера выше 5.0.4 версии.
JayDi
Вт 02 сен 2014 14:27
Форум: dbForge for MySQL
Тема: Баги 6 версии
Ответы: 93
Просмотры: 78574

Re: Баги 6 версии

И еще несколько замечаний:

1. В окне создания новой базы данных кнопка для сохранения изменений теперь называется "обновить базу". Что сначала сильно смущало. Какое же это обновление, если она еще даже не создана.

2. В окне создания резервной копии, после ее сохранения, по умолчанию всегда предлагают сохранить настройки в виде проекта. И каждый раз эта галочка включена, и ее приходится отключать. Да, каждый раз, как сделается копия. Неудобно. Было бы неплохо, чтобы этот выбор запоминался.

3. В окне создания резервной копии хотелось бы иметь дополнительную кнопку для выбора конкретного файла для сохранения (как в версиях 4 и младше). А не как сейчас -- сначала выбрать папку из ужасно неудобного окна (кстати, в новых виндоус папку можно выбирать из стандартного окна, похожего на выбор файла -- где есть избранное, строка ввода и другие возможности). Потом надо придумывать имя файла. И только после этого сохранять. Неудобно :roll:
JayDi
Вт 02 сен 2014 14:20
Форум: dbForge for MySQL
Тема: Баги 6 версии
Ответы: 93
Просмотры: 78574

Re: Баги 6 версии

Alexander писал(а):
2. Теперь по умолчанию при восстановлении данных текущая база НЕ подставляется в соответствующее поле (куда восстанавливать) и необходимо вручную выбирать из длинного списка. ОЧЕНЬ неудобно, да еще и опасно, если выбрать случайно не ту. Раньше это поле подставлялось автоматически и бралось значение из текущей базы в соединении.
Если в настройках соединения указана БД, тогда в Мастере восстановления данных автоматически выбирается данная БД, иначе - предлагается использовать ту БД, что была указана в скрипте при создании резервной копии.
Не знаю как у других, но у меня всегда используется соединение без указания конкретной базы данных. Во-первых, это нужно, если используется одно подключение сразу к нескольким базам (тестовый сервер). Во-вторых, это нужно, если используется подключение к продакшену -- хочется видеть базу, с которой работаешь.

Вообще же, при восстановлении данных (обычно, это создание тестовых баз данных) используется следующий сценарий: в списке подключений выделяется только что созданная база данных, нажимается правая кнопка мышки по ней и выбирается восстановление. Хотелось бы, чтобы в этот момент подставилась та база данных, по которой выбрали восстановление. Недавно же ведь отлично работало...
Alexander писал(а):
3. При восстановлении данных кодировка НЕ определяется, хотя ту же самую UTF-8 могли бы автоматически подставлять, например, по команде "SET NAMES utf8", которая есть в файле бекапа. Или брать ее из кодировки текстового файла, который выбирается в качестве бекапа. Или брать из кодировки той базы, в которую будут вставляться данные. Очень неудобно, т.к. ее приходится выбирать вручную из списка. А если забыть -- текст импортируется крякозябрами.
Не могли бы Вы прислать нам больше информации со скриншотами?
Немного потестировал. Оказалось, что dbForge не понимает кодировки "UTF-8 без BOM" (использовался Notepad++ для просмотра и конвертации). Пример такого файла. Собственно, именно в "UTF-8 без BOM" сохраняет стандартная утилита mysqldump (по крайней мере в версии 5.1.45).

Кстати, обратил внимание, что у mysqldump используется конструкция
/*!40101 SET NAMES utf8 */; А у вас же в исходниках применяется прямой SQL-запрос. И вообще, формат записи всех команд немного отличается. Но это так, к слову, о потенциальных проблемах.

Пример файла, который сохраняет mysqldump
Команда для его создания:

Код: Выделить всё

mysqldump.exe --host=bitnami --port=3306 --skip-no-data --skip-routines --skip-lock-tables --skip-add-locks --single-transaction --no-create-db --result-file="D:\test.sql" test1
JayDi
Сб 30 авг 2014 01:01
Форум: dbForge for MySQL
Тема: Баги 6 версии
Ответы: 93
Просмотры: 78574

Re: Баги 6 версии

Обнаружил неприятные изменения в последних релизах, связанные с бекапом данных:

1. Теперь можно восстанавливать данные только из файлов с расширением sql или zip, хотя раньше можно было выбирать любые файлы. Это очень раздражает, т.к. сторонний софт сохраняет бекапы под своим расширением.

2. Теперь по умолчанию при восстановлении данных текущая база НЕ подставляется в соответствующее поле (куда восстанавливать) и необходимо вручную выбирать из длинного списка. ОЧЕНЬ неудобно, да еще и опасно, если выбрать случайно не ту. Раньше это поле подставлялось автоматически и бралось значение из текущей базы в соединении.

3. При восстановлении данных кодировка НЕ определяется, хотя ту же самую UTF-8 могли бы автоматически подставлять, например, по команде "SET NAMES utf8", которая есть в файле бекапа. Или брать ее из кодировки текстового файла, который выбирается в качестве бекапа. Или брать из кодировки той базы, в которую будут вставляться данные. Очень неудобно, т.к. ее приходится выбирать вручную из списка. А если забыть -- текст импортируется крякозябрами.

4. В версии 6.2.280 в окне создания резервной копии базы -- если щелкнуть правой кнопкой мыши по полю с именем файла -- появится нестандартное всплывающее меню для работы с текстом (интересно, чем стандартное не устраивало-то). При этом, именно для этого поля это меню потом НЕ исчезает, а так и продолжает висеть на экране, пока по нему не щелкнуть. Даже если свернуть все окна кнопкой <Windows+D> -- оно все-равно будет висеть на экране.

Изображение
JayDi
Сб 19 окт 2013 22:03
Форум: dbForge for MySQL
Тема: Голосуйте за желаемую функциональность dbForge Studio!
Ответы: 100
Просмотры: 85389

Re: Голосуйте за желаемую функциональность dbForge Studio!

При импорте из CSV-файла не удается установить позицию строки с заголовком -- этот параметр автоматически сбрасывается на 1.

Например, когда в начале файла находятся левые данные -- хотелось бы пропустить несколько строк -- но такую вещь сейчас сделать нельзя.

Ведь основная роль поля "позиция заголовка" -- указать номер строки, в которой находятся названия колонок.

Скриншот с примером:

Изображение
JayDi
Сб 14 сен 2013 17:17
Форум: dbForge for MySQL
Тема: Голосуйте за желаемую функциональность dbForge Studio!
Ответы: 100
Просмотры: 85389

Re: Голосуйте за желаемую функциональность dbForge Studio!

УБРАТЬ CTRL+Z в редакторе таблицы или полностью переписать логику работы этой "команды"!

Господа, это просто эпик фейл тестировщиков и юзабилити-специалистов. Случайное или специальное нажатие CTRL+Z в надежде убрать результат последней операции (например, только что добавленный столбец) -- убирает ВСЕ не сохраненные в базе изменения, сделанные в таблице (например, все те 50 добавленных столбцов, над которыми до этого 30 минут сидели, не покладая рук). Мало того, что все это делается БЕЗ подтверждения таких действий, так даже БЕЗ возможности вернуть обратно!

:shock: :shock: :shock:
JayDi
Ср 19 июн 2013 12:10
Форум: dbForge for MySQL
Тема: Голосуйте за желаемую функциональность dbForge Studio!
Ответы: 100
Просмотры: 85389

Re: Голосуйте за желаемую функциональность dbForge Studio!

Alexander писал(а):
3. Ошибка при удалении индекса, который используется во внешнем ключе -- если индекс простой, то dbForge выдаст предупреждение, что его удалить нельзя. НО если индекс составной, то никакого предупреждения выводиться не будет -- появится внутренняя ошибка MySQL. Причем автоматическое создание/удаление индексов такие ситуации распознает корректно. Проверка: создать таблицу и 2 колонки; добавить внешний ключ по колонке 1, сохранить, попробовать удалить индекс по колонке 1 - появится предупреждение; создать составной индекс из двух колонок, сохранить - старый индекс удалиться и вместо него будет наш; попробовать удалить наш составной индекс - удалиться, но при сохранении появится внутренняя ошибка MySQL и ничего в реальности удалено не будет.
Мы попытались воспроизвести данную проблему на нашей стороне и ошибка появилась только в момент сохранения таблицы после удаления индекса.

Не могли бы Вы прислать нам выражения CREATE TABLE данных таблиц (в контекстном меню таблицы в Проводнике выберите 'Создать скрипт как -> CREATE'), а также уточнить, используете ли Вы последнюю сборку dbForge Studio for MySQL, v6.0.265: http://www.devart.com/ru/dbforge/mysql/ ... nload.html

Вы можете прислать ответ напрямую в нашу службу поддержки на supportATdevartDOTcom
Как раз об этой внутренней MySQL ошибки при сохранении и говорится.

Error on rename of './database_xxx/#sql-dd0_9' to './database_xxx/table1' (errno: 150)
Alexander писал(а):
1. В окне редактирования таблицы пропала горячая клавиша для вызова окна добавления новой колонки (в пятой версии была по нажатию <insert>).
В версии 6.0 реализовано новое поведение, при котором при нажатии INSERT и активном фокусе в редакторе таблицы новая колонка добавляется сразу в списке колонок в редакторе таблицы.
Редактировать столбцы прямо в таблице оказалось очень неудобным. Поэтому когда пропала клавиша быстрого вызова окна для редактирования колонки -- расстроился.



Маленькое дополнение: при редактировании уже созданной таблицы программа не дает удалить последний столбец, предупреждая, что у должен остаться хотя бы один. НО это предупреждение должно было бы выскакивать не в момент редактирования, а перед реальным сохранением в базу. Например, когда стоит задача "удалить старые и создать новые стобцы" -- в этом случае предупреждение только мешает.