Комментарии 29
А чем плох ms sql manager?
Или просто было желание написать свой велик :-)?
Или просто было желание написать свой велик :-)?
А как же конечные пользователи? Им тоже писать запросы? Легче наверное вбить нужные параметры и нажать Enter…
Ну если вы пишете выборку на основе нескольких таблиц для конечного пользователя, то для в sql manager
так же для конечного пользователя можно сделать view и он с ним будет работать как с обычной таблицей
(за исключением удаления и вставки, естественно)
так же для конечного пользователя можно сделать view и он с ним будет работать как с обычной таблицей
(за исключением удаления и вставки, естественно)
Сильна ли привязка к DBgrid и ADO?
Вместо ADO не пробовали использовать Zeos или семейство от DevArt?
Вместо ADO не пробовали использовать Zeos или семейство от DevArt?
Привязка конечно есть но не принципиальная… До ADO использовал BDE…
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине… Пока в данном случае обхожусь стандартными компонентами.
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине… Пока в данном случае обхожусь стандартными компонентами.
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине…
это только если компилировать не одним exe-шником а с внешними bpl-ками
Стандартом среди сеток являются DevExpress Quantumgrid и EhLib DBGrid
А ретро дизайн под 95-й год это фича?
Это DbGrid от Borland, или уже и не Borland, а CodeGear.
Embracadero
Позже обязательно скачаю, интересно посмотреть код.
Если таблица содержит в себе ссылку на другую таблицу — как это выглядит в интерфейсе? В виде привязанного справочника или просто редактирование, допустим, числового поля?
Позже обязательно скачаю, интересно посмотреть код.
Если таблица содержит в себе ссылку на другую таблицу — как это выглядит в интерфейсе? В виде привязанного справочника или просто редактирование, допустим, числового поля?
Если я правильно Вас понял то возможны оба варианта.
Пример есть на сайте в папке Demos\AdventureWorks
Вот кусок кода — пример связки двух справочников:
Пример есть на сайте в папке Demos\AdventureWorks
Вот кусок кода — пример связки двух справочников:
//создаем основой справочник
SLProduction := TSimpleDigestR.Create(
'select top 10 * from Production.Product P
left join Production.ProductDocument D on
D.ProductID = P.ProductID ',
'Production.Product',
edConnectionString.Text,
grbProduction,
CDOper
);
Request := 'select D.* from Production.Document D,
Production.ProductDocument P
where D.DocumentID = P.DocumentID and P.ProductID = :ProductID';
SLDocument := TSimpleDigestR.Create(
Request,
'Production.Document',
edConnectionString.Text,
grbDocuments,
CDOper,
'',
ldNone
);
//связываем два справочника
SLDocument.DataSource := SLProduction.DataSource;
SLProduction.SLOpen();
SLDocument.SLOpen();
Судя по коду — вы описали связь мастер-деталь.
Я же говорю о ситуации:
Таблица Product имеет поле IdDocument, это поле является внешним ключом к таблице Documents
Соответственно в редакции это поле не должно заполняться вручную, а должен происходить выбор записи из дочерней таблицы (в данном случае Documents). То есть обычная связь вида один ко многим/многие к одному/один к одному
Я же говорю о ситуации:
Таблица Product имеет поле IdDocument, это поле является внешним ключом к таблице Documents
Соответственно в редакции это поле не должно заполняться вручную, а должен происходить выбор записи из дочерней таблицы (в данном случае Documents). То есть обычная связь вида один ко многим/многие к одному/один к одному
А это как раз другой случай… Он есть как пример к БД cars…
Т.е. для того чтобы при вставке пользовтель вводил не идентификатор типа автомобиля (TypeID), а выбирал из справочника типов нужно задать функцию выбора из справочника (в данном случае InputTypeIDAsType):
Фукнция может произвольной, но если хотим просто показать спрвочник ('Types'), выбрать из в нем значение ('Type'), а в БД добавить ('TypeID'), то можно воспользоваться «встроенной» в DigestSDK функцией InputSimpleFieldAsNm:
Если нужно чтобы такое же поведение было например при редактировании, то достаточно просто синхронизировать наборы полей
В этом случае в поле ввода ничего ввести нельзя, а рядом автомтически появится кнопка для вызова справочника…
Т.е. для того чтобы при вставке пользовтель вводил не идентификатор типа автомобиля (TypeID), а выбирал из справочника типов нужно задать функцию выбора из справочника (в данном случае InputTypeIDAsType):
SLFields.InsertFields.FieldByName['TypeID'].ProcMode := modeUser;
SLFields.InsertFields.FieldByName['TypeID'].ProcInput := InputTypeIDAsType;
Фукнция может произвольной, но если хотим просто показать спрвочник ('Types'), выбрать из в нем значение ('Type'), а в БД добавить ('TypeID'), то можно воспользоваться «встроенной» в DigestSDK функцией InputSimpleFieldAsNm:
function InputTypeIDAsType(var OutputValue : Variant; var SLValue : Variant;
const Digest : TCommonDigest) : Boolean;
begin
Result := InputSimpleFieldAsNm(OutputValue, SLValue, Digest,
'TypeID', 'Types', 'Type', [ChooseLocate]);
end;
Если нужно чтобы такое же поведение было например при редактировании, то достаточно просто синхронизировать наборы полей
SLFields.UpdateFields.SynhronizeWith(SLFields.InsertFields);
В этом случае в поле ввода ничего ввести нельзя, а рядом автомтически появится кнопка для вызова справочника…
Эх… Где же вы были лет 5 назад! :)
Но Вы же не станете отдавать Заказчику отдельно программу выполняющую например информационный анализ содержимого БД, а отдельно программу просмотра?
Тем более что при в DBVisualizer, ms sql и др. менджеров необходимо знать структуру БД — что для конечного пользователя является зачастую неразрешимой задачей…
Тем более что при в DBVisualizer, ms sql и др. менджеров необходимо знать структуру БД — что для конечного пользователя является зачастую неразрешимой задачей…
Есть ли встроенная возможность работать с:
1. JOIN'ed выборками?
2. Иерархическими таблицами
1. JOIN'ed выборками?
2. Иерархическими таблицами
Код на первый поверхностный взгляд выглядит неплохо, аккуратно. Однако, несколько смущают подобные вещи:
Алсо, в конструкторах (напр, TCommonDigest.Create) не нужно инициализировать нулями члены класса, они будут нулевые по-умолчанию, это ж не С++ :)
Также, повсеместно встречаются в public простые поля. Да, это иногда допускается, но в таком количестве…
function TCommonDigest.FindRecordSelect
...
except
Result := False;
end;
Алсо, в конструкторах (напр, TCommonDigest.Create) не нужно инициализировать нулями члены класса, они будут нулевые по-умолчанию, это ж не С++ :)
Также, повсеместно встречаются в public простые поля. Да, это иногда допускается, но в таком количестве…
Лучше инициализировать. Кто знает что будет в будущем. Это не повредит
По поводу except практически согласен, мне просто в этом месте не нужно выводить пользователю сообщений об ошибке — поэтому сделал так (внутри фактически не перекрыты исключения в назначяемых пользователем функциях)…
По поводу инициализации — не согласен… Borland абсолютно этого не гарантирует в следующих версиях (а тем более если учесть их непостоянство....), а написать чтобы душе было спокойно — не сложно…
По поводу простых полей не совсем понял… В каком классе их переизбыток? Хотя каюсь могли проскочить в ненужные места (иногда бывает просто лень или некогда перетаскивать в property)…
По поводу инициализации — не согласен… Borland абсолютно этого не гарантирует в следующих версиях (а тем более если учесть их непостоянство....), а написать чтобы душе было спокойно — не сложно…
По поводу простых полей не совсем понял… В каком классе их переизбыток? Хотя каюсь могли проскочить в ненужные места (иногда бывает просто лень или некогда перетаскивать в property)…
>>По поводу except
Тут дело не в сообщениях пользователю, а в проглатывании потенциально произвольных исключений об ошибках. Хотя может в конкретном случае и нормально
>>По поводу инициализации — не согласен…
Вряд ли они осмелятся изменить столь фундаментальную особенность языка, это же как минимум придется переписать сам VCL и все приложения, написанные для старых версий компилятора. Нет, это решительно невозможно.
>>По поводу простых полей не совсем понял…
По-хорошему, считается хорошим кодом, если в public вообще нет открытых полей. Т.е. только property и методы, а члены классов инкапсулированы в приватных и protected-секциях. Если посмотрите исходники VCL, там это соблюдается строго.
Тут дело не в сообщениях пользователю, а в проглатывании потенциально произвольных исключений об ошибках. Хотя может в конкретном случае и нормально
>>По поводу инициализации — не согласен…
Вряд ли они осмелятся изменить столь фундаментальную особенность языка, это же как минимум придется переписать сам VCL и все приложения, написанные для старых версий компилятора. Нет, это решительно невозможно.
>>По поводу простых полей не совсем понял…
По-хорошему, считается хорошим кодом, если в public вообще нет открытых полей. Т.е. только property и методы, а члены классов инкапсулированы в приватных и protected-секциях. Если посмотрите исходники VCL, там это соблюдается строго.
Такого эксепта вообще быть не должно. Глушить все, включая такую гадость AV — верный путь к хроническому геморрою.
Паблик поля — это грубейшее нарушение инкапсуляции, так как они представляют собой состоние объекта, за которое он отвечает, но не может контролировать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DigestSDK — автоматизация работы с MSSQL на Delphi