Отображение связей в редакторе диаграммы

[Settler]

Если создать базу данных в кодировке utf8(utf8_general_ci), то связи в диаграмме не отображаются вообще. Попробовал создать в latin1. Всё отобразилось как надо. Это можно как-то исправить?

dbForge 3.50.310.1 (Русская редакция)

[AlexZ]

К сожалению, нам не удалось воспроизвести данную проблему.
Дело в том, что отображать или не отображать связи зависит только от типа движка таблицы. Только у таблиц с engine=innodb могут быть созданы внешние ключи и соответственно отображаться на диаграмме. От кодировки базы это никак не должно зависеть.

Сейчас мы работаем над возможностью создавать виртуальные связи, которые не будут привязаны к возможностям MySQL и дадут возможность связывать не только InnoDB таблицы. Эта функциональность будет доступна в dbForge Studio for MySQL v4.0.

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

[Settler]

Вот скрипт, на котором у меня получилось всё воспроизвести.
Таблицы, созданные в dbForge (table1 и table2) - отображают связи. Таблицы "скопированные" из нашей БД не отображают связи между собой. Версия MySQL 5.1.36

-- Скрипт сгенерирован Devart dbForge Studio for MySQL, Версия 3.50.310.1
-- Дата: 23.07.2009 14:59:05
-- Версия сервера: 5.1.36-community
-- Версия клиента: 4.1

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS = @@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS = 0 */;

SET NAMES 'utf8';
--
-- Описание для базы данных TestDB
--
CREATE DATABASE TestDB2
CHARACTER SET utf8
COLLATE utf8_general_ci;

USE TestDB;

--
-- Описание для таблицы BiomaterialType
--
CREATE TABLE TestDB2.BiomaterialType(
Id BIGINT (19) NOT NULL AUTO_INCREMENT,
Name VARCHAR (255) NOT NULL,
Description VARCHAR (2000) DEFAULT NULL,
PRIMARY KEY (Id),
UNIQUE INDEX BiomaterialType_Name_Unique USING BTREE (Name)
)
ENGINE = INNODB
AUTO_INCREMENT = 2
CHARACTER SET utf8
COLLATE utf8_general_ci;

--
-- Описание для таблицы Method
--
CREATE TABLE TestDB2.Method(
Id BIGINT (19) NOT NULL AUTO_INCREMENT,
Name VARCHAR (255) NOT NULL,
Description VARCHAR (2000) DEFAULT NULL,
PatientBiomaterialTypeId BIGINT (19) NOT NULL,
ResearchBiomaterialTypeId BIGINT (19) NOT NULL,
PRIMARY KEY (Id),
INDEX IX_Method USING BTREE (Id),
UNIQUE INDEX Method_Name_Unique USING BTREE (Name),
INDEX Method_PatientBiomaterialType_FK USING BTREE (PatientBiomaterialTypeId),
INDEX Method_ResearchBiomaterialType_FK USING BTREE (ResearchBiomaterialTypeId),
CONSTRAINT Method_PatientBiomaterialType_FK FOREIGN KEY (PatientBiomaterialTypeId)
REFERENCES TestDB2.biomaterialtype (Id),
CONSTRAINT Method_ResearchBiomaterialType_FK FOREIGN KEY (ResearchBiomaterialTypeId)
REFERENCES TestDB2.biomaterialtype (Id)
)
ENGINE = INNODB
AUTO_INCREMENT = 3
CHARACTER SET utf8
COLLATE utf8_general_ci;

--
-- Описание для таблицы table1
--
CREATE TABLE TestDB2.table1(
column1 BIGINT (20) NOT NULL,
column2 BIGINT (20) DEFAULT NULL,
PRIMARY KEY (column1),
INDEX table1_FK1 USING BTREE (column2),
CONSTRAINT table1_FK1 FOREIGN KEY (column2)
REFERENCES table2 (column1)
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;

--
-- Описание для таблицы table2
--
CREATE TABLE TestDB2.table2(
column1 BIGINT (20) NOT NULL,
PRIMARY KEY (column1)
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;

/*!40014 SET FOREIGN_KEY_CHECKS = @OLD_FOREIGN_KEY_CHECKS */;

[AlexZ]

Мы попробовали воспроизвести на Вашем скрипте - у нас все работает..

Для уточнения ситуации, ответьте на следующие вопросы:
1. после выполнения указанного скрипта, движок Ваших таблиц действительно InnoDb? Чтобы это проверить выберите в dbForge Studio в Проводнике созданную таблицу и посмотрите её свойства.
2. Также после создания таблицы проверьте наличие внешних ключей в папке Ограничения у данной таблицы в Проводнике dbForge Studio for MySQL. Если нет - значит ключи не создались.. тогда и на диаграмме их не будет. В случае, если MySQL не поддерживает InnoDb движок, то он игнорирует создание внешнего ключа, а создает только обычный индекс, который на диаграмме не будет отображаться как связь.
3. Почему в Вашем скрипте создается база TestDB2, а USE делается базе TestDB? Если Вы не правили этот скрипт руками, значит есть баг в нашем приложении.. Пожалуйста, уточните данный вопрос.

[Settler]

Да, я немного правил его. Переименовывал схему в TestDB2, чтобы попробовать по создать ещё одну схему. Оставляю ссылку на скриншот, на котором видно, что все связи есть и все ссылки тоже есть, однако на диаграмме они не отображаются. Есть вероятность, что это из-за имени таблиц? Дело в том, что в настройках MySQL у нас стоит: Make table names: 0 - Store as Created, Case Sensitive. У вас в ссылках на таблицы имена с маленькой буквы (оно наверно и понятно, ведь в описании схем в MySQL они с такими именами и хранятся). А таблицы на самом деле начинаются с заглавной буквы.

Скриншот:
pic.ipicture.ru/uploads/090724/thumbs/EnNT2ERUZ7.jpg

Updated:
Да, проблемы именно в этом! Только что в TestDB2 создал таблицу с именем "Table3" ( с заглавной буквы). Сделал ссылку из table2 на Table3. Ссылка создалась но связь не отобразилась.

[AlexZ]

Да, Вы правы, проблема именно в том, что включена опция MySQL сервера. Мы исправим эту проблему в dbForge Studio for MySQL 3.60.

[AlexZ]

Вы не могли бы ответить на один вопрос: какой результат у Вас возвращает запрос "show create table testdb2.Method"?
Заранее, спасибо за ответ.

[Settler]

Увы, я уже удалил тестовые схемы. Восстановил TestDB2 скриптом, который выложил тут и подправил "Use TestDB2".
Результат:

Table: Method

Create Table:
CREATE TABLE `Method` (
`Id` bigint(19) NOT NULL AUTO_INCREMENT,
`Name` varchar(255) NOT NULL,
`Description` varchar(2000) DEFAULT NULL,
`PatientBiomaterialTypeId` bigint(19) NOT NULL,
`ResearchBiomaterialTypeId` bigint(19) NOT NULL,
PRIMARY KEY (`Id`),
UNIQUE KEY `Method_Name_Unique` (`Name`) USING BTREE,
KEY `IX_Method` (`Id`) USING BTREE,
KEY `Method_PatientBiomaterialType_FK` (`PatientBiomaterialTypeId`) USING BTREE,
KEY `Method_ResearchBiomaterialType_FK` (`ResearchBiomaterialTypeId`) USING BTREE,
CONSTRAINT `Method_PatientBiomaterialType_FK` FOREIGN KEY (`PatientBiomaterialTypeId`) REFERENCES `biomaterialtype` (`Id`),
CONSTRAINT `Method_ResearchBiomaterialType_FK` FOREIGN KEY (`ResearchBiomaterialTypeId`) REFERENCES `biomaterialtype` (`Id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8

Так же попробовал этот запрос на нашей основной базе. Все ссылки: REFERENCES 'tablename', написаны в нижнем регистре.
Ещё очень странно то, что если сделать следующий запрос к MySQL: "select * from information_schema.referential_constraints" и посмотреть на столбец REFERENCED_TABLE_NAME, то там все таблицы записаны в нижнем регистре. Я не знаю, по какой причине MySQL хранит их там именно так и как он потом не путается, если стоит параметр "Case Sensitive"...

Понял, почему не путается... Нельзя создать 2 таблицы "Table1" и "table1", даже с выставленным параметром. По-этому, для нас этот параметр только для удобства работы с таблицами, потому что они у нас отображаются на классы в программе.

[AlexZ]

Да, Вы абсолютно правы. Дело в том, что опция lower-case-table-names в MySQL существует только для удобства использования имен таблиц. Внутри в метаданных MySQL все приводит к нижнему регистру.

В любом случае, ту проблему, о которой Вы писали, мы исправили. Исправление будет доступно в dbForge Studio for MySQL v3.60.