Спасибо! Тронут.
Относительно последней версии (9-й) продукта dbForge Studio испытываю только самые положительные эмоции. Правда, я ещё только начал ею пользоваться, но уже виден значительный прогресс. В то же время сохраняется преемственность версий снизу вверх. Это далеко не у всех девелоперских фирм получается (например, у Microsoft получается редко), но позволяет юзерам не переучиваться каждый раз, начиная почти с ноля. Дальнейших успехов!
Найдено 74 результата
- Ср 27 май 2020 18:35
- Форум: dbForge for MySQL
- Тема: Новая версия - старая проблема с русскими символами
- Ответы: 5
- Просмотры: 15310
- Вт 26 май 2020 10:42
- Форум: dbForge for MySQL
- Тема: Новая версия - старая проблема с русскими символами
- Ответы: 5
- Просмотры: 15310
Re: Новая версия - старая проблема с русскими символами
Прошу прощения за мою рассеянность.
В соединении localhost (utf8) моя база оказалась в кодировке koi8u, а не utf8u, как я написал. Нигде я не указывал koi8!
Теперь я совсем не понимаю, какими резонами пользуется dbForge Studio 2020 for MySQL v9.0.304 при назначении кодировок . Одно утешение: русский язык всё-таки появился.
В соединении localhost (utf8) моя база оказалась в кодировке koi8u, а не utf8u, как я написал. Нигде я не указывал koi8!
Теперь я совсем не понимаю, какими резонами пользуется dbForge Studio 2020 for MySQL v9.0.304 при назначении кодировок . Одно утешение: русский язык всё-таки появился.
- Вт 26 май 2020 10:24
- Форум: dbForge for MySQL
- Тема: Новая версия - старая проблема с русскими символами
- Ответы: 5
- Просмотры: 15310
Re: Новая версия - старая проблема с русскими символами
Неожиданно эта проблема разрешилась сама собой. У меня теперь русский язык есть в базе, и вот как это произошло.
Видя, что никакие мои потуги по перекодировке не помогают, в частности при помощи операции "Изменить соединение", я в сердцах воспользовался операцией "Новое соединение". После этого даже не пришлось восстанавливать базу из резервной копии - она сразу появилась, причём с кодировкой koi8u и русским языком в таблицах!
Я удовлетворён, но поделюсь предположением. Может быть, это поможет доработать версию 9. Ведь всё-таки восстановление базы из резерва не в той кодировке, в которой она была сохранена,- это глюк, который требует починки.
Итак, когда я инсталлировал dbForge Studio 2020 (или MySQL Connector NET, точно не помню), требовалось ввести имя базы данных. Я ввёл, предположим, mybase. В результате было создано соединение с именем mybase.localhost (?!) с CharacterSet по умолчанию, а умолчание = latin1. Когда потом я в это соединение залил базу mybase из резервного файла, она тоже приняла кодировку latin1, а не ту, которая явно была указана в файле: "SET NAMES 'utf8';". Вот где зарыта собака. Когда же я создал новое соединение (по умолчанию было создано соединение с именем, как и ожидалось, localhost), то на этот раз оно без вопросов было создано с "Character Set=utf8" (?!), и база mybase в нём оказалась почти (utf8u) с той кодировкой, которая была указана в SQL-скрипте бэкапа (utf8).
Извините за внимание!
Видя, что никакие мои потуги по перекодировке не помогают, в частности при помощи операции "Изменить соединение", я в сердцах воспользовался операцией "Новое соединение". После этого даже не пришлось восстанавливать базу из резервной копии - она сразу появилась, причём с кодировкой koi8u и русским языком в таблицах!
Я удовлетворён, но поделюсь предположением. Может быть, это поможет доработать версию 9. Ведь всё-таки восстановление базы из резерва не в той кодировке, в которой она была сохранена,- это глюк, который требует починки.
Итак, когда я инсталлировал dbForge Studio 2020 (или MySQL Connector NET, точно не помню), требовалось ввести имя базы данных. Я ввёл, предположим, mybase. В результате было создано соединение с именем mybase.localhost (?!) с CharacterSet по умолчанию, а умолчание = latin1. Когда потом я в это соединение залил базу mybase из резервного файла, она тоже приняла кодировку latin1, а не ту, которая явно была указана в файле: "SET NAMES 'utf8';". Вот где зарыта собака. Когда же я создал новое соединение (по умолчанию было создано соединение с именем, как и ожидалось, localhost), то на этот раз оно без вопросов было создано с "Character Set=utf8" (?!), и база mybase в нём оказалась почти (utf8u) с той кодировкой, которая была указана в SQL-скрипте бэкапа (utf8).
Извините за внимание!
- Пт 22 май 2020 14:56
- Форум: dbForge for MySQL
- Тема: Новая версия - старая проблема с русскими символами
- Ответы: 5
- Просмотры: 15310
Новая версия - старая проблема с русскими символами
Забыл добавить, что в DataGridView программ русский язык выглядит нормально, как раньше.
1) Работаю в Windows 7 на Visual Studio 2013, пишу программу на C#.
2) В строке соединения с БД пишу: "... CharSet=cp1251 ...".
1) Работаю в Windows 7 на Visual Studio 2013, пишу программу на C#.
2) В строке соединения с БД пишу: "... CharSet=cp1251 ...".
- Пт 22 май 2020 14:44
- Форум: dbForge for MySQL
- Тема: Новая версия - старая проблема с русскими символами
- Ответы: 5
- Просмотры: 15310
Новая версия - старая проблема с русскими символами
Доброго здоровья всем коллегам - сидельцам по домам!
Давненько я не был на форуме, причины не было. Но вот решил обновиться до версии 9.0.304 - и влип.
Установил всё по умолчанию. После загрузки бэкапа старой базы вместо русских символов в полях типа VARCHAR вижу одни знаки вопроса. Ранее я много раз переходил на новые версии dbForge Studio for MySQL, но такого уже давно не было.
Все таблицы типа INNODB, созданы с кодировкой utf8.
Файл резервной копии был сохранён из старой версии dbForge Studio (не помню, какой, но давней) с установкой кодировки по умолчанию: Unicode (UTF-8) - Codepage 65001.
Теперь у восстановленной базы данных, в которой "???????????", установка: Charset = latin1, Collation Name = latin1_swedish_ci (?!), хотя таблицы остались с кодировкой utf8 (utf8_general_ci).
Посоветуйте, как в этой ситуёвине перевести с русского на русский язык!
Давненько я не был на форуме, причины не было. Но вот решил обновиться до версии 9.0.304 - и влип.
Установил всё по умолчанию. После загрузки бэкапа старой базы вместо русских символов в полях типа VARCHAR вижу одни знаки вопроса. Ранее я много раз переходил на новые версии dbForge Studio for MySQL, но такого уже давно не было.
Все таблицы типа INNODB, созданы с кодировкой utf8.
Файл резервной копии был сохранён из старой версии dbForge Studio (не помню, какой, но давней) с установкой кодировки по умолчанию: Unicode (UTF-8) - Codepage 65001.
Теперь у восстановленной базы данных, в которой "???????????", установка: Charset = latin1, Collation Name = latin1_swedish_ci (?!), хотя таблицы остались с кодировкой utf8 (utf8_general_ci).
Посоветуйте, как в этой ситуёвине перевести с русского на русский язык!
- Ср 18 фев 2015 15:07
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Да, так гораздо лучше!
- Ср 18 фев 2015 14:16
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Я так и делаю.
И все же прямого ответа хотя бы на первый вопрос я так и не получил. Видимо это новый, современный стиль работы - стиль эффективных манагеров.
Терпение мое лопнуло.
Всего вам хорошего
И все же прямого ответа хотя бы на первый вопрос я так и не получил. Видимо это новый, современный стиль работы - стиль эффективных манагеров.
Терпение мое лопнуло.
Всего вам хорошего
- Ср 18 фев 2015 12:00
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Опять "мыло и мочало - начинай сначала"! И Вы же пишете, что я у Вас отнимаю драгоценное время! Я уже всё описал. Хотите еще? Пожалуйста - по "Профили", то что Вы советовали:
"Новая строка перед открывающейся скобкой" - скобка при сохранении перескакивает в предыдущую строку, т.е. опция срабатывает при форматировании, но не сохраняется.
"Пробел перед открывающейся скобкой" в заголовке процедуры (в "Параметры") не работает.
Я попробовал только 4-5 опций, и 2 из них не работают - это 40-50%. Можно сделать вывод, и с остальными опциями дело обстоит не лучше. Любой нормальный тестировщик уже вернул бы программу на доработку.
Когда я работал зав. отделом разработки ПО в ГИВЦ Москвы (и довольно долго), то если бы мы сдавали в эксплуатацию (в продажу) столь недоработанную версию, нас всех давно бы уволили. А у Вас это считается в порядке вещей, наверное. И Вы еще долго будете дорабатывать и дорабатывать, не потрудившись протестировать сами то, что у Вас получается, а используя в качестве тестировщиков пользователей. А нам не до этого! И Ваш продукт так и остается хронически недоработанным (примеров за годы накопилось много, но я не собираюсь тратить время на новые препирательства).
Именно поэтому я и спрашиваю: Можете сделать так, чтобы в backup текст записывался так, как его отформатировал пользователь, хоть и вручную? Если можете, то вопросов больше не будет, кроме "Когда?", потому что этого достаточно, чтобы обойти все ваши, мягко говоря, "идеи" насчет форматирования. Вы же пишете в ответ все что угодно, но на главный, выделенный вопрос не отвечаете. И добавляю второй вопрос: Зачем при сохранении сбивается даже настроенное (а не только пользовательское) форматирование - какая в этом есть такая необходимость и почему это невозможно преодолеть? Это всего 2 вопроса, на которые я ожидаю ответы.
"Новая строка перед открывающейся скобкой" - скобка при сохранении перескакивает в предыдущую строку, т.е. опция срабатывает при форматировании, но не сохраняется.
"Пробел перед открывающейся скобкой" в заголовке процедуры (в "Параметры") не работает.
Я попробовал только 4-5 опций, и 2 из них не работают - это 40-50%. Можно сделать вывод, и с остальными опциями дело обстоит не лучше. Любой нормальный тестировщик уже вернул бы программу на доработку.
Когда я работал зав. отделом разработки ПО в ГИВЦ Москвы (и довольно долго), то если бы мы сдавали в эксплуатацию (в продажу) столь недоработанную версию, нас всех давно бы уволили. А у Вас это считается в порядке вещей, наверное. И Вы еще долго будете дорабатывать и дорабатывать, не потрудившись протестировать сами то, что у Вас получается, а используя в качестве тестировщиков пользователей. А нам не до этого! И Ваш продукт так и остается хронически недоработанным (примеров за годы накопилось много, но я не собираюсь тратить время на новые препирательства).
Именно поэтому я и спрашиваю: Можете сделать так, чтобы в backup текст записывался так, как его отформатировал пользователь, хоть и вручную? Если можете, то вопросов больше не будет, кроме "Когда?", потому что этого достаточно, чтобы обойти все ваши, мягко говоря, "идеи" насчет форматирования. Вы же пишете в ответ все что угодно, но на главный, выделенный вопрос не отвечаете. И добавляю второй вопрос: Зачем при сохранении сбивается даже настроенное (а не только пользовательское) форматирование - какая в этом есть такая необходимость и почему это невозможно преодолеть? Это всего 2 вопроса, на которые я ожидаю ответы.
- Ср 18 фев 2015 11:06
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Спасибо, но это все мелочи, с которыми, как я только что написал, можно мириться.
А как, все-таки, насчет бэкапа?
А как, все-таки, насчет бэкапа?
- Ср 18 фев 2015 10:00
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Еще по поводу форматирования.
Я добился, что при сохранении процедуры сохраняется мое форматирование. Кроме первого аргумента, который упорно перескакивает вместе с открывающей скобкой на ту же строку, где имя процедуры, а остальные аргументы, написанные в следующих строках, прижимаются к левому краю - этого победить мне не удалось. Но это еще можно было терпеть.
Однако! После создания резервной копии (backup) и восстановления из нее все форматирование пользователя пропадает и опять появляется Ваше навязчивое форматирование по умолчанию. Нельзя ли сделать так, чтобы из beckup все восстанавливалось так, как было? Ведь именно для этого и существует beckup. Тем более, что Ваш backup - это текстовый файл, так зачем записывать в него текст, искажая форматирование пользователя, если можно сделать просто копию текста (для этого нужно только копировать полностью каждую строку, вместе с пробелами и табуляцией).
Я добился, что при сохранении процедуры сохраняется мое форматирование. Кроме первого аргумента, который упорно перескакивает вместе с открывающей скобкой на ту же строку, где имя процедуры, а остальные аргументы, написанные в следующих строках, прижимаются к левому краю - этого победить мне не удалось. Но это еще можно было терпеть.
Однако! После создания резервной копии (backup) и восстановления из нее все форматирование пользователя пропадает и опять появляется Ваше навязчивое форматирование по умолчанию. Нельзя ли сделать так, чтобы из beckup все восстанавливалось так, как было? Ведь именно для этого и существует beckup. Тем более, что Ваш backup - это текстовый файл, так зачем записывать в него текст, искажая форматирование пользователя, если можно сделать просто копию текста (для этого нужно только копировать полностью каждую строку, вместе с пробелами и табуляцией).
- Вт 17 фев 2015 18:17
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
На F5 и на другие горячие клавиши я не нажимал (потому что обалдел), только кликал мышью.
Версия dbForge Studio for MySQL последняя: 6.3.341
Версия MySQL Server: 5.5 - работает на том же компьютере, где и программы разрабатываются, запускается при запуске компьютера. До сих пор эта версия СУБД не подводила.
После того случая я сделал еще несколько изменений, и при клике мышью на кнопке "Обновить данные" обновления действительно происходили. Поэтому я бы не настаивал на том, чтобы вы немедленно начинали свои исследования. Если такие случаи будут повторяться, я сообщу.
Знаю по своей практике, что бывают глюки, которые отловить так и не удается, хотя на это тратится много времени, а потом они не повторяются.
Версия dbForge Studio for MySQL последняя: 6.3.341
Версия MySQL Server: 5.5 - работает на том же компьютере, где и программы разрабатываются, запускается при запуске компьютера. До сих пор эта версия СУБД не подводила.
После того случая я сделал еще несколько изменений, и при клике мышью на кнопке "Обновить данные" обновления действительно происходили. Поэтому я бы не настаивал на том, чтобы вы немедленно начинали свои исследования. Если такие случаи будут повторяться, я сообщу.
Знаю по своей практике, что бывают глюки, которые отловить так и не удается, хотя на это тратится много времени, а потом они не повторяются.
- Вт 17 фев 2015 15:30
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Ключевыми словами в моем сообщении были слова "контент" (содержимое таблицы) и "не изменяется". Как Вы думаете, на какую кнопку я стал бы нажимать, чтобы обновить таблицу? В контексте, в котором это сообщение впервые появилось, было совершенно понятно, что речь идет об изменении данных:
Обычно для обновления надо нажать на кнопку с двумя противоположными стрелочками (первую слева в инструментальной панели над DataGridView, в котором представлены данные таблицы). Эта операция не подействовала. Тогда я стал нажимать на кнопку с такой же иконкой, но с надписью "Обновить объект" в нижней панели,- тоже без эффекта. Таблица типа INNODB, там всего 68 записей. После закрытия транзакции с помощью COMMIT не менялось (иногда) измененное значение в поле типа DECIMAL(10,1). Сообщите, пожалуйста, что еще я могу сообщить, чтобы Вам не пришлось угадывать мысли?Кроме того, Вы должны прекрасно знать, что бывают т.н. "мерцающие" ошибки, которые при одинаковых условиях то возникают, то нет. Вот, например, еще одна новость, которую я ранее в Вашем продукте не замечал: иногда при указании мышью соответствующих кнопок контент таблицы данных не изменяется (а должен был измениться). Моя программа на C# уже запросила БД и я вижу изменения, а в Студии их нет. Не помогает погашение и новое отображение таблицы, помогает только выход из Студии совсем. И это происходит не всегда, а иногда, при неизменном коде программы - так что, дело здесь Не в незавершенной транзакции (да она и НЕ должна мешать Студии ни при каких обстоятельствах).
- Вт 17 фев 2015 10:31
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Я все-таки решил потратить еще время. Я его тоже уже и так немало потратил в надежде, что Вы меня поймете, и тоже мог бы сделать за это время более полезные дела. Но Вы меня просто не понимаете, хоть Вы и lead developer.
Я написал совершенно четко и доходчиво: "Иногда при указании мышью соответствующих кнопок контент таблицы данных не изменяется (а должен был измениться)". Вы же мне в предыдущем ответе стали объяснять про структуру таблицы, про автодополнение кода, про сечетание Ctrl+Shift+R (кстати, Ctrl+Shift многие используют для переключения русский/английский, это сочетание не годится). При чем здесь это всё? Речь идет о том, что при обновлении таблицы не видны изменения, сделанные из сторонней программы, изменившей ее содержание (а не структуру). Это крупнейший недостаток! Надо бить в набат и срочно выяснять, в чем тут дело, а не пытаться замазать его демагогией. Ибо такой инструмент, который то показывает изменения, то не показывает, никому, в общем-то, не нужен. Он недостоверен, ему нельзя доверять (я даже долго не мог поверить тому, что Студия стала так глючить, и сначала искал ошибки в своей программе, которых не оказалось). Поздравляю, Вам удалось все-таки испортить хороший продукт!
Что же касается 200 опций профиля форматирования, то зачем это надо было делать так сложно, когда вполне достаточно было опций в режиме "Сервис"-"Параметры"- "Текстовый редактор" - "Форматирование"? Теперь там почти пусто. Вот о чем речь.
Похоже, что команда просто высасывает из пальца себе работу тогда, когда продукт достиг своего апогея. Теперь будет только все хуже и хуже, и мои вопли не помогут.
Я написал совершенно четко и доходчиво: "Иногда при указании мышью соответствующих кнопок контент таблицы данных не изменяется (а должен был измениться)". Вы же мне в предыдущем ответе стали объяснять про структуру таблицы, про автодополнение кода, про сечетание Ctrl+Shift+R (кстати, Ctrl+Shift многие используют для переключения русский/английский, это сочетание не годится). При чем здесь это всё? Речь идет о том, что при обновлении таблицы не видны изменения, сделанные из сторонней программы, изменившей ее содержание (а не структуру). Это крупнейший недостаток! Надо бить в набат и срочно выяснять, в чем тут дело, а не пытаться замазать его демагогией. Ибо такой инструмент, который то показывает изменения, то не показывает, никому, в общем-то, не нужен. Он недостоверен, ему нельзя доверять (я даже долго не мог поверить тому, что Студия стала так глючить, и сначала искал ошибки в своей программе, которых не оказалось). Поздравляю, Вам удалось все-таки испортить хороший продукт!
Что же касается 200 опций профиля форматирования, то зачем это надо было делать так сложно, когда вполне достаточно было опций в режиме "Сервис"-"Параметры"- "Текстовый редактор" - "Форматирование"? Теперь там почти пусто. Вот о чем речь.
Похоже, что команда просто высасывает из пальца себе работу тогда, когда продукт достиг своего апогея. Теперь будет только все хуже и хуже, и мои вопли не помогут.
- Пн 16 фев 2015 18:51
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Все Ваши скудные настройки я уже перепробовал. Я уже несколько лет пользуюсь этой средой, и мне есть, с чем сравнивать. Я Вам еще раз советую: верните пользовательскую настройку форматирования! Все равно Вам придется это сделать, так не откладывайте: Вы уже явно теряете своих приверженцев. А разбирать каждую мелочь, чтобы Вы мне каждый раз доказывали, что все у Вас правильно,- на это времени нет (в этом у меня тоже есть длительный опыт общения с Вами, и каждый раз черное оказывалось белым). У Вас должны быть тестировщики, опытные в SQL,- пусть они работают лучше, если постановщики задач и программеры сами не понимают, что творят.
На этом наше бесполезное общение позвольте считать исчерпанным.
На этом наше бесполезное общение позвольте считать исчерпанным.
- Пн 16 фев 2015 15:46
- Форум: dbForge for MySQL
- Тема: Голосуйте за желаемую функциональность dbForge Studio!
- Ответы: 100
- Просмотры: 85536
Re: Голосуйте за желаемую функциональность dbForge Studio!
Я не проставил 2 частицы НЕ в предпоследней строке. Читайте, пожалуйста, так:
...дело здесь НЕ в незавершенной транзакции (да она и НЕ должна мешать Студии ни при каких обстоятельствах).
...дело здесь НЕ в незавершенной транзакции (да она и НЕ должна мешать Студии ни при каких обстоятельствах).