вадят.е. если в функции есть поле таблицы - конструктор не понимает, что это функция
и парсит не правильноИсправлено в новом билде беты. Обновите на 107-й.
вадярррррррррррррррррррыыыыыЭто тоже исправлено в 6.0.107-м.

HettА где-то есть открытый баг трекер или сюда писать?
Вот сейчас нашел такой небольшой баг: если открыть таблицу на просмотр данных и установить сортировку путем клика по заголовку столбца, то при нажатии на F5 сотрировка сбрасывается на дефолтную.Исправлено в 6.0.107-м билде

вадяпри создании резервной копии, если база большая (у меня таблица 59000, поля картинки, та что затыкалась в предыдущих версиях)
при отмене сздания, после ответов на все вопросы, сервер не останавливает посылку данных, мне не удалоь этого дождатьтся ~1мин. пришлось перегрузить mysql.Это тоже в 107-м исправлено.

вадяэто
13985183

исправлено?Да. Проверьте.

вадявозникало мысль - может для ускорения сравнения сравнивать не данные а хэш?Подобная мысль нам приходила еще на стадии проектирования самой первой версии компараторов (лет так 6 назад). Уже точно не помню, но мы исследовали возможность использования, и нашли случаи, когда компаратор мог идентифицировать разные данные, как идентичные. Используемый сейчас вариант, в 100% случаев гарантирует правильный результат идентификации разных записей, но требует пересылки всех записей сравнения из всех столбцов обеих баз данных на локальный пк по сети. Другой способ кардинального уменьшения трафика - не пересылать одинаковые данные или "исторические" данные. SQL Server, например, позволяет определить статус данных и задача уже стоит на будущие версии компараторов для этого сервера. Позволит ли MySQL дать такую возможность, очень сомневаюсь. Еще известная проблема компаратора - при сравнении, он "выедает" все ресурсы сети и другие сетевые клиенты получают таймауты, и возможности ограничить пропускную способность у компаратора в текущих версиях нет. Эта задачу тоже предстоит решить в следующих версиях.

вадя... возник вопрос: сначала данные скачиваются чтоб сравнится, а потом чтоб скопироваться. Или скачанные для сравнения сохраняются? тогда как с теми что изменились в в источнике и уже скачались...
в общем каков механизм , на что расчитывать для случая больших данных? поподробнее плиззз.Вычитка данных и сравнение происходит одновременно, сравненные данные архивируются в другом потоке и сохраняются в дисковый кэш. Если локальный ПК имеет 2 и более ядер, то прирост производительности, по сравнению с одноядерными, составляет прибл 10%. После вычитки всех данных происходит синхронизация требуемых из дискового кэша (опять же, пересылкой данных по сети). Это довольно долгий процесс, особенно при больших объемах данных. За это время конечно же база данных может изменится и данные в базе окажутся рассинхронизированными, поэтому, чем чаще происходит синхронизация, тем актуальнее данные в базе. Изначально компараторы проектировались не для репликации баз данных - задача компаратора помочь разработчику или аналитику найти отличия между Dev базой и Test базой. Для целей репликации правильнее использовать стандартные механизмы (какие есть в MySQL и в SQL Server), и в данном случае актуальность данных будет выше, а объем сетевого трафика ниже.вадякак насчет поддержки mysql 5.6ххх?Пока что 6-я версия студии официально не поддерживает MySQL 5.6. Но это означает лишь то, что если будут появятся специфические баги на этой версии сервера мы не сможем обещать их исправления в ближайших билдах. Мы прогнали автотесты на этой версии сервера и лишь небольшая их часть провалилась. Например, сделана поддержка микросекунд в типах данных TIME, DATETIME и TIMESTAMP, но компараторы, экспорт данных, редактор данных этого не заметит. Т.е. если не использовать новые специфические фичи MySQL 5.6. студия будет работать так же, как и с остальными версиями MySQL.

вадядизайнер запросов не помнит своего места, открываетсая всегда в маленьком экране и в центре
а надо чтоб помнило и монитор
и опять надо делать "Выравнять элементы на диаграмме"Воспроизвели. Исправим.

вадяу вкладок таблиц и процедур есть "подвкладки" их указатели/заголовки отображены вверху
а у запросов - "подвкладки" почему-то в низу = вызывает путаницу, по привычке ищшь вверху , а нету....
желательно однотипно сделать - вверхуВсё верно. Это разные по смыслу кнопки (закладки).
Те, что у визуальных редакторов вверху - это можно сказать группированные опции объекта.
Те, что у SQL документа внизу - это виды документа (виды представления документа).

Мы рады сообщить о долгожданном релизе dbForge Studio for MySQL, v6.0 .
Все замеченные баги в бета-версии были исправлены. Благодарим всех, кто принял в этом активное участие!