Отзовитесь, кто нибудь :))

← →
Polevi (2001-12-14 12:03) [0]

Кто работал с MIDAS - MS SQL через ADO ??
Уже две недели бьюсь - запись не добавить :))) !!!
Ответьте, пожалуйста, или на е-mail напишите...

← →
Polevi (2001-12-14 15:01) [1]

Неужели никто не использовал данную схему?
Мда..
Плохо :(

← →
Romkin (2001-12-14 15:20) [2]

Так в чем именно проблема?

← →
Polevi (2001-12-14 15:53) [3]

Проблема вот в чем
Для того чтобы сообщить в ClientDataset ID добавленной записи я действую след. образом:
DatasetProvider.Options:=poPropogateChanges;
DatasetProvider.ResolveToDataset:=true;

procedure TRDM.dspBeforeUpdateRecord(Sender: TObject; SourceDS: TDataSet;
DeltaDS: TCustomClientDataSet; UpdateKind: TUpdateKind;
var Applied: Boolean);
begin
if UpdateKind=ukInsert then
begin
SourceDS.Insert;
SourceDS.FieldByName("Name").Value:=DeltaDS.FieldByName("Name").OldValue;
SourceDS.Post;
DeltaDS.FieldByName("ID").NewValue:=SourceDS.FieldByName("ID").Value;
Applied:=true;
end;
end;

на клиенте делаю Insert;ApplyUpdates(0);RefreshRecord;

Все работает, НО

Именно при инсерте на Appserver возникает "Unknown error" - сейчас, следуя твоему совету, буду исследовать это дело на предмет утечки памяти
Первоначально использовал ADOQuery - сейчас перешел на ADODataset - проблема не решилась..

И проблема номер 2
Чтобы сделать Insert - Post - ADO требует чтобы хотя бы одно поле было заполнено - но я же не могу для каждого DatasetProvuder"a прописывать BeforeUpdateRecord!!! - хочется универсальности какой нибудь, чтобы обработчик был один на всех.

И наконец просто интересно как народ решает данную проблему - когда я гляжу на свой код меня терзают смутные сомнения :))

← →
Romkin (2001-12-14 16:02) [4]

Скорее всего, BeforeUpdateRecord при ResolveDataSet не нужно, и без него должно пройти (на крайняк при RefreshRecord)
А поля заполняй по умолчанию на onNewREcord, прямо в ADODataSEt

← →
Romkin (2001-12-14 16:16) [5]

При ResolveDataSet провайдер работает с таблицей, буквально
SourceDS.Insert;
SourceDS.FieldByName("Name").Value:=DeltaDS.FieldByName("Name").OldValue;
SourceDS.Post;
поэтому попробуй поработать с TAdoDataSet в двухзвенке, если будет ошибка - значит, дело в ADO.

← →
Polevi (2001-12-14 16:46) [6]

Если не делать BeforeUpdateRecord - получаю ошибку - "Record not found or changed by another user"

← →
Romkin (2001-12-14 17:30) [7]

Вставь в afterPost AdoDataSet.RefreshRecord
и замкни одно событие на все датасеты

← →
Polevi (2001-12-14 17:43) [8]

RefreshRecord это метод TClientDataset
в ADODataset его нет

← →
Romkin (2001-12-14 17:59) [9]

Все, пришел спец.
гРИТ, в persistent field, у того поля, которое autoinc, передается как TIntegerField, надо установить свойство autoinc (в ADODataSet). Тогда все пойдет автоматом
Немного не понимаю, но вроде вообще refreshrecord не надо

← →
Polevi (2001-12-14 18:19) [10]

твой спец не прав :((
не работает это - я проверял
я читал какуюто борландовскую статью на эту тему, там написано что TField.AutogenerateValue:=arAutoInc работает только для BDE

← →
Xpdeveloper (2001-12-15 03:50) [11]

2Polevi:
Я смотрю ты все ищешь проблем для себя.
ДБ-модель Делфей - издали совместима с ADO МС-вской, и поэтому лучше импортировать библиотеку типов (которая тоже некорректно импортируется) или работать напрямую с обьектами ADO через CreateComObject.
Оно и быстрее и надежней.
А если последнюю фичу брать - ADO.Net - тут для Борланда крепкий орех попадется. Сама по себе - конфетка, а будучи пристроенной к классам Делфи - обретет крайне обрезанный вид.

← →
Polevi (2001-12-15 15:47) [12]

2Xpdeveloper
Спасибо за помощь :)))
А что - ты уже видел реализацию .NET на Delphi?

← →
Xpdeveloper (2001-12-18 00:10) [13]

2Polevi: На Делфи поддержка .Net это все разве к началу 3 года может быть выйдет. Вполне возможно что сама среда Делфи изменится круто. А так ADO.Net официально как пришлепка Visual Studio.Net то есть вместе с ней выйдет в феврале 2002.
Я пробовал ее импортировать в Делфи - пока бесполезно так как нынешняя реализация не поддерживает COM и как с COM_обьектом еще непонятно - будет ли сделано в релизе. Пока толку мало, для этого на борту должна стоять .NEt FrameWork.
Но о скорострельности и надежности сказки уже рассказывают.
Sorry за пустые комментарии, но действительно - зачем пользовать проблематичную модель классов BDE, когда можно работать напрямую, пользуя импортируемую библиотеку типов. Или хотя бы wrapper-классы других производителей, которые затачивают не под BDE.
Но портировать ADO.Net под Делфи будет легче - слава богу там уже нет ненавистных variants с которыми Делфи так и не научилась работать. Все очень строго и типизировано.

← →
panov (2001-12-18 07:05) [14]

>Xpdeveloper (15.12.01 03:50)
"А если последнюю фичу брать - ADO.Net - тут для Борланда крепкий орех попадется"
Это не для Борланда крепкий орех, а изврат от Microsoft.

Отзовитесь, кто нибудь :)) Найти похожие ветки