TStringGrid и скрытые колонки

[krab]

Ну тогда подкину вам пример где поле ID желательно:
у вас есть два клиента Иванов Иван Иванович. Один заведен раньше, а другой позже. И вам нужно выбрать именно правильного клиента при заведении договора. Как вы их отличать будете?

У решений №1-№2 такой проблемы нет. Решение №3 - сугубо как пример неудачного подхода. Поле ID нужно в любом случае, конечно.

А по поводу скрытия полей.. Никто вам не мешает заполнять DBGrid нужными полями (TColumns) при работе программы (настройка DBGrid может происходить при создании формы).

А зачем это может понадобится?

Но работать нужно не с данными в DBGrid, а имено с данными в датасете и работайте с вашими невидимыми полями себе в удовольствие.

ДБГридов у меня нет. Обхожусь StringGrid'ами, в которые сам загружаю данные с помощью sqlite3_exec из модуля sqlite3. Это позволяет разбить приложение на модуль взаимодействия с БД и модули пользовательского интерфейса, обрабатывающие нажатия на кнопки и т. п.

Если делать на database-aware компонентах и датасетах во-первых, замаюсь с глюками, во-вторых, сложно будет отделить взаимодействие с БД от работы с пользовательским интерфейсом. Либо будет свалка из датасетов на все случаи жизни.

[Padre_Mortius]

У решений №1-№2 такой проблемы нет

Эта проблема есть не у программы, а у пользователя, который с ней работает.

Если делать на database-aware компонентах и датасетах во-первых, замаешься с глюками, во-вторых, сложно будет отделить взаимодействие с БД от работы с пользовательским интерфейсом.

Примеры глюков можно? Это не очень сложно, главное начать.

[krab]

Эта проблема есть не у программы, а у пользователя, который с ней работает.

Это уже из области философии.

Примеры глюков можно? Это не очень сложно, главное начать.

http://freepascal.ru/forum/viewtopic.php?p=40080#p40080

[Padre_Mortius]

Либо будет свалка из датасетов на все случаи жизни.

Попробуйте создание некоторых датасетов в рантайме (например, для вставки и удаления). Не будет свалки. Сам использую таким образом. На последнем маленьком проекте (около 10 таблиц) в TDatamodule всего 2 датасета, остальное работает в рантайме

Добавлено спустя 32 секунды:

Padre_Mortius писал(а):Примеры глюков можно? Это не очень сложно, главное начать.


viewtopic.php?p=40080#p40080

Он уже поправлен)

[krab]

Попробуйте создание некоторых датасетов в рантайме (например, для вставки и удаления). Не будет свалки. Сам использую таким образом. На последнем маленьком проекте (около 10 таблиц) в TDatamodule всего 2 датасета, остальное работает в рантайме

ОК, для действий, которые изменяют БД - создание в рантайме. Логично.

Задаете запросы на выборку и подключаете к ДБгридам тоже в рантайме?

Вообще можно попробовать.

Но у решений №1-№2 еще плюс в возможности настроить вид компонентов прямо в среде. А тут придется еще проверять как выглядит грид в рантайме, подгонять под размеры шрифта... Такого как тут в Лазарусе нет (если что, обсудить лучше в той теме).

Он уже поправлен)

Sqlite3Connection должен работать более-менее. А если понадобится доступ к MySQL или к Firebird? Или даже к MS SQL. Про MySQLConnection слышал плохие отзывы. А так разница между низкоуровневыми биндингами к sqlite и mysql небольшая, перейти от одного к другому сравнительно нетрудно. Нет такой зависимости от компонент.

[alexs]

krab
Всё-же вы не правы.
Как раз использование DB компонентов позволяет в некотором роде абстрагироваться от сервера БД,
А вобще писать программу, которая сможет работать с ЛЮБЫМ сервером БД - это значит не использовать весь функционал, которые эти сервера предосталвяют - обычно такие программы используют функционал на уровне, который предоставляет самый СЛАБЫЙ сервер.
Я уже говорил тут, что полностью отвязаться от сервера - это МИФ.
И для работы с данными с конкретного сервера лучше использовать компоненты, заточенные под этот сервер.

[Padre_Mortius]

Задаете запросы на выборку и подключаете к ДБгридам тоже в рантайме?

Я не использую динамическое создание dataset с подключением к DBGrid, но и такое возможно. Создаете dataset при создании формы, а при ее уничтожении уничтожаете dataset. Но для простых операций которые возвращают, например сумму по полю или количество строк, можно и динамически содать.

Sqlite3Connection должен работать более-менее.

Не в курсе. Для работы со sqlite3 использую sqlite3dataset и для вставки(удаления или других простых операций) PSqlite3

А так разница между низкоуровневыми биндингами к sqlite и mysql небольшая, перейти от одного к другому сравнительно нетрудно.

Зависит от сложности и размера проекта. При переносе ПО с одной базы на другую в любом случае затраты по времени будут приличные.

Про MySQLConnection слышал плохие отзывы.

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

[krab]

Как раз использование DB компонентов позволяет в некотором роде абстрагироваться от сервера БД,

По сути, выбранный мной подход это тоже абстракция от сервера БД. Просто выполненная в "процедурной" форме, а не объектно-ориентированной и только с используемыми мной возможностями.

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

Те компоненты, которые я видел(*Connection) предоставляли только базовый функционал(выполнение SQL-запросов и dataset). "Заточенности" там нет. А вот как раз низкоуровневый биндинг позволит полностью воспользоваться всеми возможностями СУБД, если это понадобится.

[Padre_Mortius]

Вы почему-то забываете про различия в языке SQL-запросов

[krab]

Я не использую динамическое создание dataset с подключением к DBGrid, но и такое возможно.

Как же тогда у вас 2 датасета в датамодуле на 10 таблиц в БД? Запросы позволяют выбирать данные из нескольких таблиц, но все равно какая-то диспропорция. Или часть данных сугубо "служебная" и не показывается пользователю?

Не в курсе. Для работы со sqlite3 использую sqlite3dataset и для вставки(удаления или других простых операций) PSqlite3

То есть, насколько помню тот компонент, каждый датасет держит свое соединение с БД? Не возникает ли проблем из-за блокирования базы и т. п.?

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

Это да, но не хотелось бы постоянно спотыкаться и работать от баг-репорта до баг-репорта.

Добавлено спустя 1 минуту 42 секунды:

Вы почему-то забываете про различия в языке SQL-запросов

Которые не нивелируются компонентами. То есть все равно придется менять текст запроса в поле SQL у компонента. Сам он запрос не составит, разве что совсем простой, который и так везде работает (SELECT * FROM Table1).

[Padre_Mortius]

Пользователю показываются все данные. Просто в проекте в рантайме перенастраиваются параметры компонентов на нужные в данный период времени.

То есть, насколько помню тот компонент, каждый датасет держит свое соединение с БД? Не возникает ли проблем из-за блокирования базы и т. п.?

Какие блокировки? sqlite3 это не многопользовательская база. А закрывать датасет, когда отображаемые данные становятся не нужными, очень даже полезно

[krab]

Какие блокировки? sqlite3 это не многопользовательская база. А закрывать датасет, когда отображаемые данные становятся не нужными, очень даже полезно

Пару раз сталкивался с ошибкой наподобие "БД заблокирована" во время выполнения запросов на добавление. Помогало закрытие консоли, в которой был открыт консольный клиент SQLite (sqlite3.exe).

Даже если закрывать датасеты, когда они не нужны, в одной форме их может одновременно отображаться несколько.

[Padre_Mortius]

Имено этим отличается работа на низком уровне с работой посредством sql-запросов. Если я создаю запрос

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

select id, name, surname, birthday from mytable

, то работать я буду именно с данной выборкой не блокируя таблицу

Добавлено спустя 4 минуты 55 секунд:

в одной форме их может одновременно отображаться несколько

Ради бога, используйте любое число датасетов на одной форме, но если вы закрыли форму смысла держать датасет открытым нет никакого. Если данные взимосвязаны, то стоит попробовать использовать всевозможные join'ы в select'овой выборке

[krab]

Имено этим отличается работа на низком уровне с работой посредством sql-запросов.

Чем отличается? Не совсем понимаю противопоставления работы на низком уровне и работы через sql-запросы.
Когда я делаю:

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

  sql := 'SELECT * FROM table1;';
  rc  := sqlite3_exec(sqlite, PChar(sql), @MyCallback, nil, @ErrMsg);

Это на низком уровне или через запросы? Я называл "низкоуровневым" все, что делается с помощью функций модуля sqlite напрямую, а не через компоненты.

[Padre_Mortius]

Работа на низком уровне (т.е. напрямую с базой) блокирует данные, В вашем случае на низком уровне работал sqlite3.exe.
Приведенный пример это тоже скульные запросы, но уровень абстакции ниже, чем у того же датасета