Основы работы с БД

[Troublemaker]

Меня здорово смущает, что это свойство типа string...

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

Логично. Я и сам так думал. Но как мне передать в это строковое свойство значение "истинно" булевой переменной? Ведь она, фактически ( sizeof(boolean)=4 ) - длинное целое. И как грид "видит" это значение, чтобы отобразить его в виде чекбокса?

Edit: странности со строками - мой собственный косяк, разобрался.

Зачем к логическому полю обращаешся как к целому?

Раз уж оно - 32-битное целое, то хочется мне инвертировать его, поксорив с $ffff - хочу именно в таком виде сделать memdataset.savetofile.

А на фига, кстати, у dataset свойство FileName, если SaveToFile требует имени файла в качестве одного из параметров?

Не вопрос, а размышление: нигде не увидел упоминания о том, что после использования функций dataset.[first,last,next,prev] датасет переходит в режим бровса, и если надо пошагово пройтись по всем записям, например, в каждой поправить одно и то же поле, после каждого, скажем, некста, приходится принудительно вызывать .edit

[alexs]

И что-то я запутался со строками:

Ты тут что-то не правильно понял.
Сначала ты должен создать набор данных - описать структуру данных.

MDS.FieldDefs.Add('Stri',ftString,20); //это поле с номером 1, перед ним есть еще одно, с номером ноль. Длина строки ДВАДЦАТЬ

Именно эта строка это и делает.

strr:=MDS.Fields[1].AsString;b:=Length(strr);

А вот это ты уже работаеш с самими данными.
Но перед тем как взять из набора данны, ты должен что либо туда записать.
т.е. такого вида:
MDS.Open; // начинаеш работу с данными, открываеш датасет
MDS.Append;
MDS.Fields[1].AsString:='Тут произвольная строка';
MDS.Post;
//А вот это уже можно считать
strr:=MDS.Fields[1].AsString; //Тут в твоей переменно будет твоя произвольная строка
b:=Length(strr);//А вот здесь ты возьмёш её длинну

Но как мне передать в это строковое свойство значение "истинно" булевой переменной? Ведь она, фактически ( sizeof(boolean)=4 ) - длинное целое. И как грид "видит" это значение, чтобы отобразить его в виде чекбокса?

Я ж тебе код прям писал. Размер логического типа - это дело компилятора а не твоё. Всё равно там хранится только 2 значения (в логической перменной, а не воле набора данных!) ПРосто у тебя платформах 32-битная - вот и размер такой. На других платформах он может быть другим.
Просто присваивай значение:
MDS.FieldByName('Твоё логической поле').AsBoolean;
А грид знает, что если поле логическо - то отображать в виде чека. Или смотри в колонке грида свойство ButtonStyle

[Troublemaker]

И что-то я запутался со строками:

Ты тут что-то не правильно понял.

См. edit выше - это был мой косяк, у меня строка имела фактическую длину 2 символа

Я ж тебе код прям писал.

Речь не о том. Тип поля - ftBoolean. В датасете 20 записей, значения в булевы поля пишутся рандомно - где-то true, где-то false. Но грид для всех этих полей показывает пустые чекбоксы, хотя поля типа ftString и ftInteger показываются и редактируются без проблем.

Так какими же должны быть Value(Un)Checked, чтобы в этом столбце нормально отображались "истинно" булевы поля, а не упомянутые m_guest char(1) в роли булевых?

[v-t-l]

Я бы, все же, рекомендовал использовать SDFDataset. У него и методы есть LoadFromStream и SaveToStream - можно будет организовать расшифровку/шифрование файла налету (например с помощью библиотеки DCrypt). А memdataset - то ли глюкалово сплошное, то ли просто капризный очень .

[Troublemaker]

Я бы, все же, рекомендовал использовать SDFDataset.

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

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

Коллеги, так мне кто-нибудь ответит: dataset и datasource - они умеют поддерживать только одну таблицу каждый или несколько? Я не могу достучаться до wiki, чтобы глянуть пример для TDBF.

[m_guest]

Совершено примитивнейший пример работы грида с чекбоксами(БД из одного логического поля):
http://slil.ru/25755347

[alexs]

Так какими же должны быть Value(Un)Checked

если ничего не меняеш - то при указании поля типа ftBoolean DBGrid сам начинает отображать в колонке чеки. Ничего не надо специально устанавливать. Проверил на RxMemoryData.
если интересно - просто посмотри в исходниках модуля DBGrids методы
TCustomDBGrid.ColumnEditorStyle(
procedure TCustomDBGrid.DefaultDrawCell(aCol, aRow: Integer; aRect: TRect;
aState: TGridDrawState);
там это всё прозрачно написано.

[Troublemaker]

Совершено примитивнейший пример работы грида с чекбоксами(БД из одного логического поля):
http://slil.ru/25755347

Посмотрел. Не понял - из какой палитры берется Dbf1TMP1? У меня ничего подобного нет.
Соответственно грид рисуется пустым, вообще без записей. Путь к базе перепрописал с учетом расположения программы.

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

там это всё прозрачно написано.

Угу. Даже стало понятно, почему для булевых полей эти свойства Value(Un)Checked игнорируются

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

procedure TCustomDBGrid.DrawCheckboxBitmaps(aCol: Integer; aRect: TRect;
  F: TField);
...
    if F.DataType=ftBoolean then
      if F.IsNull then
         AState := gcbpGrayed
      else
      if F.AsBoolean then
        AState := gcbpChecked
      else
        AState := gcbpUnChecked
    else
      if ValueMatch(F.AsString, TColumn(ColumnFromGridColumn(aCol)).ValueChecked) then
        AState := gcbpChecked
      else
      if ValueMatch(F.AsString, TColumn(ColumnFromGridColumn(aCol)).ValueUnChecked) then
        AState := gcbpUnChecked
      else
        AState := gcbpGrayed


Но в гриде-то чекбоксы всё равно все пустые. Сейчас еще попробую сделать поле символьным и явно назначить для него T/F...

[Sergei I. Gorelkin]

Коллеги, так мне кто-нибудь ответит: dataset и datasource - они умеют поддерживать только одну таблицу каждый или несколько? Я не могу достучаться до wiki, чтобы глянуть пример для TDBF.

Только одну. Если быть точнее, то "изнутри" dataset может быть основан не только на таблице, но и на результатах SQL-запроса, включающего данные из нескольких таблиц. Но "снаружи" он все равно эквивалентен таблице, т.е. представляет собой набор однотипных записей.

[m_guest]

из какой палитры берется Dbf1TMP1

Просто я сделал статическое поле, ему автоматом присвоилось имя Dbf1TMP1
Для создания стат. пол дважды щелкаете на компоненте Dbf1
Далее,такое поле редактируется через Инспектор Объектов

[Troublemaker]

Только одну.

Стало быть, для "коллекции" про которую я говорил немного раньше, мне надо заводить четыре датасета, раз у меня нет внешней БД?

По вопросу о чекбоксах.
Переопределил булево поле как char, явно прописал для столбца cbsCheck... и заработало. По крайней мере в гриде чекбоксы рисует как положено для true/false. Похоже, всё-таки, что-то не то с передачей или анализом содержимого boolean полей, хотя в коде процедуры, которая рисует чекбоксы в гриде, всё действительно прозрачно и логично. Так почему же она не работает?

Осталось разобраться, почему не работает отдельный чекбокс, привязанный к полю.
(блин! время уже - 4:08 утра... )

[Attid]

Стало быть, для "коллекции" про которую я говорил немного раньше, мне надо заводить четыре датасета, раз у меня нет внешней БД?

с нетерпением жду когда ты все таки решишь что БД в твоем случае не нужна =)

[Vadim]

оюсь в учебниках и т.п., но никак не могу понять простую, вроде бы, вещь: что, собственно, есть dataset? Это - одна таблица данных или набор из нескольких таблиц?

TDataSet - это не таблица, это набор данных готовый для обработки клиентом. Соответственно этот набор может быть взят/сформирован как из одной таблицы (этим ведает потомок TDataSet - TTable), так и из нескольких таблиц (этим ведает потомок TDataSet - TQuery).

Если из нескольких, то почему createtable не имеет параметров?

Из вышесказанного следует вполне логический вывод: поскольку к таблицам, которые хранит база данных, TDataSet имеет лишь косвенное отношение, то какие параметры могут быть? Есть два варианта:
1. Твой DataSet берёт данные из одной таблицы. Зачем параметры, если таблица создаётся из тех данных, что заданы в FieldDefs? Ведь там всё что нужно задано, а название таблицы задаётся уже в свойстве потомка - TTable.TableName. К DataSet'у название не имеет никакого отношения.
2. Если DataSet из нескольких таблиц. CreateTable создаёт одну таблицу, а не несколько. Какие могут быть параметры? Хочешь создать таблицу (одну, именно одну... ), тогда в TQuery.SQL так и пишешь:

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

CREATE TABLE название_таблицы (Поле1 Тип(размер). Поле2 Тип(размер,...)

Функция CreateTable тут никаким боком не учавствует, ибо убить базу с таким её применением - раз плюнуть.

[Troublemaker]

с нетерпением жду когда ты все таки решишь что БД в твоем случае не нужна =)

Сударь, вы мне невпервой это говорите. Ваши контрпредложения?

TDataSet - это не таблица, это набор данных готовый для обработки клиентом. Соответственно этот набор может быть взят/сформирован как из одной таблицы (этим ведает потомок TDataSet - TTable), так и из нескольких таблиц

Угу, спасибо. Становится понятнее.

Итак, меня в один голос убеждают, что БД мне здесь не нужна. А что тогда? Я не прошу решать мою задачу за меня, но от идей совсем не откажусь.

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

таблица создаётся из тех данных, что заданы в FieldDefs? Ведь там всё что нужно задано, а название таблицы задаётся уже в свойстве потомка - TTable

Стало быть, если рассуждать логически, для моей задачи нужно в датасете прописать все необходимые поля, а потом, комбинируя их, создавать нужные таблицы, или как?

Что до убиения базы, то всё верно, если бы не одно "но": таблица создается в памяти, поэтому ее "смерть" будет страшить только меня и только на этапе проектирования.

[Vadim]

Стало быть, если рассуждать логически, для моей задачи нужно в датасете прописать все необходимые поля, а потом, комбинируя их, создавать нужные таблицы

Не таблицы, а таблицу.
В первую очередь - планирование. Если планируется один датасет связать с одной таблицей, то проблем нет, она и создаётся по описанию. Если же один датасет связан с несколькими таблицами, то нужно предусмотреть какой-то иной механизм создания таблиц, более удобный.

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

Хорошо бы, если бы все ошибки вылазили только на этапе проектирования.

Итак, меня в один голос убеждают, что БД мне здесь не нужна. А что тогда?

Надо подумать, в каком виде данные будут лежать на диске. То что именно на диске, а не в памяти - данные эти нужно каким-то образом передавать туда сюда и лучшей формы передачи набора данных, чем файл, пока ещё не придумали.
Вот какие есть альтернативы:
1. MemDS. Достоинства - данные из неё могут быть выгружены в файл и загружены из файла, т.е. их можно куда-то передавать без постоянной привязки к интернету. Недостатки - скверно работает компонент в Лазарусе, проблемы с интерактивным редактированием данных в визуальном компоненте.
2. CSV-файл. Достоинства - для интерактивного редактирования существует работающие компоненты, типа SdfDataSet, передача данных без привязки к интернету, данные в файл можно забить в любом текстовом редакторе. Недостатки - опять же без программы можно посмотреть всё его содержимое, в том числе и содержащиеся там ответы. Кодировка русского языка. Впрочем, это недостаток неспецифичный, а присутствующий в том или ином виде во всех других способах, только текстовый файл нужно явно перекодировать.
3. DBF. Самый, на мой взгляд, универсальный формат хранения данных, почти текст. Достоинства - куда ни плюнь везде есть компоненты и куча программ для работы с DBF. Кодировку русского языка можно вводить автоматически, для этого в заголовке DBF-файла есть специальное поле, так что проблем с чтением на любой ОС не будет в принципе, если только шрифты будут. Недостатки - поскольку это почти тот же текст, то он тоже легко читается просто так.