Как стать автором
Обновить

Комментарии 29

А чем плох ms sql manager?
Или просто было желание написать свой велик :-)?
А как же конечные пользователи? Им тоже писать запросы? Легче наверное вбить нужные параметры и нажать Enter…
Ну если вы пишете выборку на основе нескольких таблиц для конечного пользователя, то для в sql manager
так же для конечного пользователя можно сделать view и он с ним будет работать как с обычной таблицей
(за исключением удаления и вставки, естественно)
Ну а также за исключением сортировки, поиска (нужно будет знать синтаксис sql и имена полей) ну и прочих дополнительных функций :-)
Сильна ли привязка к DBgrid и ADO?
Вместо ADO не пробовали использовать Zeos или семейство от DevArt?
Привязка конечно есть но не принципиальная… До ADO использовал BDE…
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине… Пока в данном случае обхожусь стандартными компонентами.
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине…

это только если компилировать не одним exe-шником а с внешними bpl-ками

Стандартом среди сеток являются DevExpress Quantumgrid и EhLib DBGrid
Такие мысли были — но руки пока не дошли :-)
А ретро дизайн под 95-й год это фича?
Это DbGrid от Borland, или уже и не Borland, а CodeGear.
Embracadero

Позже обязательно скачаю, интересно посмотреть код.

Если таблица содержит в себе ссылку на другую таблицу — как это выглядит в интерфейсе? В виде привязанного справочника или просто редактирование, допустим, числового поля?
Если я правильно Вас понял то возможны оба варианта.

Пример есть на сайте в папке 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). То есть обычная связь вида один ко многим/многие к одному/один к одному
А это как раз другой случай… Он есть как пример к БД cars…

Т.е. для того чтобы при вставке пользовтель вводил не идентификатор типа автомобиля (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 назад! :)
Примерно лет 5 назад DigestSDK уже был… Но тогда не было хабра :-)
Ну в качестве бесплатного инструмента, может быть, он и хорош. Однако ведь уже есть универсальные интерфейсы, такие как DBVisualizer, поддерживающий практически любые БД и к тому же кроссплатформенный.
image
Но Вы же не станете отдавать Заказчику отдельно программу выполняющую например информационный анализ содержимого БД, а отдельно программу просмотра?
Тем более что при в DBVisualizer, ms sql и др. менджеров необходимо знать структуру БД — что для конечного пользователя является зачастую неразрешимой задачей…
Есть ли встроенная возможность работать с:
1. JOIN'ed выборками?
2. Иерархическими таблицами
Код на первый поверхностный взгляд выглядит неплохо, аккуратно. Однако, несколько смущают подобные вещи:

function  TCommonDigest.FindRecordSelect
...
  except
    Result := False;
  end;


Алсо, в конструкторах (напр, TCommonDigest.Create) не нужно инициализировать нулями члены класса, они будут нулевые по-умолчанию, это ж не С++ :)

Также, повсеместно встречаются в public простые поля. Да, это иногда допускается, но в таком количестве…
Лучше инициализировать. Кто знает что будет в будущем. Это не повредит
Это называется избыточный код, такие вещи не меняются
Вот из-за таких людей как вы и сложился образ Delphi-программиста-говнокодера.
Не лучше. Это в будущем не изменится — на это ВСЯ объектная модель дельфи стоит.
По поводу except практически согласен, мне просто в этом месте не нужно выводить пользователю сообщений об ошибке — поэтому сделал так (внутри фактически не перекрыты исключения в назначяемых пользователем функциях)…

По поводу инициализации — не согласен… Borland абсолютно этого не гарантирует в следующих версиях (а тем более если учесть их непостоянство....), а написать чтобы душе было спокойно — не сложно…

По поводу простых полей не совсем понял… В каком классе их переизбыток? Хотя каюсь могли проскочить в ненужные места (иногда бывает просто лень или некогда перетаскивать в property)…
>>По поводу except
Тут дело не в сообщениях пользователю, а в проглатывании потенциально произвольных исключений об ошибках. Хотя может в конкретном случае и нормально

>>По поводу инициализации — не согласен…
Вряд ли они осмелятся изменить столь фундаментальную особенность языка, это же как минимум придется переписать сам VCL и все приложения, написанные для старых версий компилятора. Нет, это решительно невозможно.

>>По поводу простых полей не совсем понял…
По-хорошему, считается хорошим кодом, если в public вообще нет открытых полей. Т.е. только property и методы, а члены классов инкапсулированы в приватных и protected-секциях. Если посмотрите исходники VCL, там это соблюдается строго.
Такого эксепта вообще быть не должно. Глушить все, включая такую гадость AV — верный путь к хроническому геморрою.
Паблик поля — это грубейшее нарушение инкапсуляции, так как они представляют собой состоние объекта, за которое он отвечает, но не может контролировать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории