Комментарии 29
А чем плох ms sql manager?
Или просто было желание написать свой велик :-)?
Или просто было желание написать свой велик :-)?
+2
А как же конечные пользователи? Им тоже писать запросы? Легче наверное вбить нужные параметры и нажать Enter…
0
Ну если вы пишете выборку на основе нескольких таблиц для конечного пользователя, то для в sql manager
так же для конечного пользователя можно сделать view и он с ним будет работать как с обычной таблицей
(за исключением удаления и вставки, естественно)
так же для конечного пользователя можно сделать view и он с ним будет работать как с обычной таблицей
(за исключением удаления и вставки, естественно)
0
Сильна ли привязка к DBgrid и ADO?
Вместо ADO не пробовали использовать Zeos или семейство от DevArt?
Вместо ADO не пробовали использовать Zeos или семейство от DevArt?
+1
Привязка конечно есть но не принципиальная… До ADO использовал BDE…
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине… Пока в данном случае обхожусь стандартными компонентами.
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине… Пока в данном случае обхожусь стандартными компонентами.
0
Использовать сторонние компоненты без особой надобности не хочется — необходимо будет в это случае их устанавливать на каждой машине…
это только если компилировать не одним exe-шником а с внешними bpl-ками
Стандартом среди сеток являются DevExpress Quantumgrid и EhLib DBGrid
0
А ретро дизайн под 95-й год это фича?
0
Это DbGrid от Borland, или уже и не Borland, а CodeGear.
0
Embracadero
Позже обязательно скачаю, интересно посмотреть код.
Если таблица содержит в себе ссылку на другую таблицу — как это выглядит в интерфейсе? В виде привязанного справочника или просто редактирование, допустим, числового поля?
Позже обязательно скачаю, интересно посмотреть код.
Если таблица содержит в себе ссылку на другую таблицу — как это выглядит в интерфейсе? В виде привязанного справочника или просто редактирование, допустим, числового поля?
0
Если я правильно Вас понял то возможны оба варианта.
Пример есть на сайте в папке 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();
0
Судя по коду — вы описали связь мастер-деталь.
Я же говорю о ситуации:
Таблица Product имеет поле IdDocument, это поле является внешним ключом к таблице Documents
Соответственно в редакции это поле не должно заполняться вручную, а должен происходить выбор записи из дочерней таблицы (в данном случае Documents). То есть обычная связь вида один ко многим/многие к одному/один к одному
Я же говорю о ситуации:
Таблица Product имеет поле IdDocument, это поле является внешним ключом к таблице Documents
Соответственно в редакции это поле не должно заполняться вручную, а должен происходить выбор записи из дочерней таблицы (в данном случае Documents). То есть обычная связь вида один ко многим/многие к одному/один к одному
0
А это как раз другой случай… Он есть как пример к БД 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);
В этом случае в поле ввода ничего ввести нельзя, а рядом автомтически появится кнопка для вызова справочника…
0
Эх… Где же вы были лет 5 назад! :)
0
0
Но Вы же не станете отдавать Заказчику отдельно программу выполняющую например информационный анализ содержимого БД, а отдельно программу просмотра?
Тем более что при в DBVisualizer, ms sql и др. менджеров необходимо знать структуру БД — что для конечного пользователя является зачастую неразрешимой задачей…
Тем более что при в DBVisualizer, ms sql и др. менджеров необходимо знать структуру БД — что для конечного пользователя является зачастую неразрешимой задачей…
0
Есть ли встроенная возможность работать с:
1. JOIN'ed выборками?
2. Иерархическими таблицами
1. JOIN'ed выборками?
2. Иерархическими таблицами
0
Код на первый поверхностный взгляд выглядит неплохо, аккуратно. Однако, несколько смущают подобные вещи:
Алсо, в конструкторах (напр, TCommonDigest.Create) не нужно инициализировать нулями члены класса, они будут нулевые по-умолчанию, это ж не С++ :)
Также, повсеместно встречаются в public простые поля. Да, это иногда допускается, но в таком количестве…
function TCommonDigest.FindRecordSelect
...
except
Result := False;
end;
Алсо, в конструкторах (напр, TCommonDigest.Create) не нужно инициализировать нулями члены класса, они будут нулевые по-умолчанию, это ж не С++ :)
Также, повсеместно встречаются в public простые поля. Да, это иногда допускается, но в таком количестве…
0
Лучше инициализировать. Кто знает что будет в будущем. Это не повредит
0
По поводу except практически согласен, мне просто в этом месте не нужно выводить пользователю сообщений об ошибке — поэтому сделал так (внутри фактически не перекрыты исключения в назначяемых пользователем функциях)…
По поводу инициализации — не согласен… Borland абсолютно этого не гарантирует в следующих версиях (а тем более если учесть их непостоянство....), а написать чтобы душе было спокойно — не сложно…
По поводу простых полей не совсем понял… В каком классе их переизбыток? Хотя каюсь могли проскочить в ненужные места (иногда бывает просто лень или некогда перетаскивать в property)…
По поводу инициализации — не согласен… Borland абсолютно этого не гарантирует в следующих версиях (а тем более если учесть их непостоянство....), а написать чтобы душе было спокойно — не сложно…
По поводу простых полей не совсем понял… В каком классе их переизбыток? Хотя каюсь могли проскочить в ненужные места (иногда бывает просто лень или некогда перетаскивать в property)…
+1
>>По поводу except
Тут дело не в сообщениях пользователю, а в проглатывании потенциально произвольных исключений об ошибках. Хотя может в конкретном случае и нормально
>>По поводу инициализации — не согласен…
Вряд ли они осмелятся изменить столь фундаментальную особенность языка, это же как минимум придется переписать сам VCL и все приложения, написанные для старых версий компилятора. Нет, это решительно невозможно.
>>По поводу простых полей не совсем понял…
По-хорошему, считается хорошим кодом, если в public вообще нет открытых полей. Т.е. только property и методы, а члены классов инкапсулированы в приватных и protected-секциях. Если посмотрите исходники VCL, там это соблюдается строго.
Тут дело не в сообщениях пользователю, а в проглатывании потенциально произвольных исключений об ошибках. Хотя может в конкретном случае и нормально
>>По поводу инициализации — не согласен…
Вряд ли они осмелятся изменить столь фундаментальную особенность языка, это же как минимум придется переписать сам VCL и все приложения, написанные для старых версий компилятора. Нет, это решительно невозможно.
>>По поводу простых полей не совсем понял…
По-хорошему, считается хорошим кодом, если в public вообще нет открытых полей. Т.е. только property и методы, а члены классов инкапсулированы в приватных и protected-секциях. Если посмотрите исходники VCL, там это соблюдается строго.
0
Такого эксепта вообще быть не должно. Глушить все, включая такую гадость AV — верный путь к хроническому геморрою.
0
Паблик поля — это грубейшее нарушение инкапсуляции, так как они представляют собой состоние объекта, за которое он отвечает, но не может контролировать.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DigestSDK — автоматизация работы с MSSQL на Delphi