Как программно сохранить изменения в связанном с БД DataCombo? Или...
связанном через Adodc с таблицей. Ничего в хелпах не нашел. Сам придумал только кострукцию
Adodc1.Recordset.Move 0. Но тут проблема: как быть если нужно перейти к следующей записи в этом
Recordset без сохранения данных, ведь при MoveNext данные сохраняются автоматом, насколько я понял
из хелпа? Заранее большое спасибо!
Подскажите пожалуйста способ программно сохранить данные, которые выставлены юзером в DataCombo,
связанном через Adodc с таблицей. Ничего в хелпах не нашел. Сам придумал только кострукцию
Adodc1.Recordset.Move 0. Но тут проблема: как быть если нужно перейти к следующей записи в этом
Recordset без сохранения данных, ведь при MoveNext данные сохраняются автоматом, насколько я понял
из хелпа? Заранее большое спасибо!
Если честно, я делаю обычно отвязанный комбобокс, а потом просто запросом сохраняю изменения из него.
Подскажите пожалуйста способ программно сохранить данные, которые выставлены юзером в DataCombo,
связанном через Adodc с таблицей. Ничего в хелпах не нашел. Сам придумал только кострукцию
Adodc1.Recordset.Move 0. Но тут проблема: как быть если нужно перейти к следующей записи в этом
Recordset без сохранения данных, ведь при MoveNext данные сохраняются автоматом, насколько я понял
из хелпа? Заранее большое спасибо!
Связанный DataCombo ведь не понимает, хочешь ты сохранять данные или нет. Он умеет только сохранять. Позтому для таких целей он просто не годится.
Связанный DataCombo ведь не понимает, хочешь ты сохранять данные или нет. Он умеет только сохранять. Позтому для таких целей он просто не годится.
Умеет - отучим. Не хочет - заставим :)
Не верю, что невозможно! А что если для начала бороться примитивным методом: делать обычный рефреш перед переходом на новую запись - ведь тогда все изменения и не сохранятся. Хорошо было бы конечно обойтись без доп. обращений к базе...
Если честно, я делаю обычно отвязанный комбобокс, а потом просто запросом сохраняю изменения из него.
Этот способ, бесспорно достоин права на существование :) Но только в моем случае я поставил себе задачу - меньше кода - больше автоматики! Поэтому пытаюсь заставить работать автоматически все, что вижу :)) Поиски кратчайшего варианта продолжаются :)
Этот способ, бесспорно достоин права на существование :) Но только в моем случае я поставил себе задачу - меньше кода - больше автоматики! Поэтому пытаюсь заставить работать автоматически все, что вижу :)) Поиски кратчайшего варианта продолжаются :)
А зря. Более короткий код вовсе не означает более быструю работу и меньшие требования к ресурсам. Хотя. если задался целью "победить" автоматику, то это очень даже интересно - если появится время, подключусь к этому делу. А ты. если что. сообщишь о результатах, ладно?;)
А зря. Более короткий код вовсе не означает более быструю работу и меньшие требования к ресурсам. Хотя. если задался целью "победить" автоматику, то это очень даже интересно - если появится время, подключусь к этому делу. А ты. если что. сообщишь о результатах, ладно?;)
Ок. обязательно!
А точнее автоматику нужно не "победить", а заставить работать на нас. И вообще, мне почему-то хочется верить, что в MS работают все-таки профессионал, иначе зачем им деньги такие платят?
Давайте для начала исходить, что их контролы ДОЛЖНЫ работать хорошо. А там проверим.
Скажете я романтик? :)
Ок. обязательно!
А точнее автоматику нужно не "победить", а заставить работать на нас. И вообще, мне почему-то хочется верить, что в MS работают все-таки профессионал, иначе зачем им деньги такие платят?
Давайте для начала исходить, что их контролы ДОЛЖНЫ работать хорошо. А там проверим.
Скажете я романтик? :)
В чём-то я с тобою согласен. Но, согласись, привязанные контролы всё же создавались с целью облегчить разработку приложений вообще, а не оптимизировать код приложений. К тому же они универсальны, а универсальность всегда имеет следствием ущерб оптимальности.
Жаль, что никто не хочет признаваться, что хоть раз имел с этим дело :)
Дискуссия затянулась :) Меньше слов - больше дела!
Жаль, что никто не хочет признаваться, что хоть раз имел с этим дело :)
Приятель, ты ломишься в наглухо заколоченную дверь или наоборот в распахнутую настежь (не знаю, как сказать правильно, чтобы ты понял). Менять значение в связанном контроле - это все равно, что ковыряться непосредственно в таблце, с которой он связан. Единственный способ сохранить старое значение поля, с которым он связан, - это ввести его ручками заново. И никак иначе.
Приятель, ты ломишься в наглухо заколоченную дверь или наоборот в распахнутую настежь (не знаю, как сказать правильно, чтобы ты понял). Менять значение в связанном контроле - это все равно, что ковыряться непосредственно в таблце, с которой он связан. Единственный способ сохранить старое значение поля, с которым он связан, - это ввести его ручками заново. И никак иначе.
Думаю, нет. Есть такое нитересное событие для DataControl - называется Validate. Очень подозреваю, что оно как раз для этого. Я, конечно использую не DataControl, a ADODataControl и именнно Validate там и нет, но. поскольку эти контролы во многом родственные, видимо, там можно найти заменитель. Вчера просто не хватило времени посмотреть. Так, что, думаю, не стоит спешить с выводами ;)
Думаю, нет. Есть такое нитересное событие для DataControl - называется Validate. Очень подозреваю, что оно как раз для этого. Я, конечно использую не DataControl, a ADODataControl и именнно Validate там и нет, но. поскольку эти контролы во многом родственные, видимо, там можно найти заменитель. Вчера просто не хватило времени посмотреть. Так, что, думаю, не стоит спешить с выводами ;)
Слухай, раз контролы родственные, то попробуй объявлять ADODataControl поздним связыванием с событиями и там поищи Validate, или создай его сам.
Слухай, раз контролы родственные, то попробуй объявлять ADODataControl поздним связыванием с событиями и там поищи Validate, или создай его сам.
Спасибо за идею :)
Столько всего уже сделать можно - просто не знаю за что и браться :)
Спасибо за идею :)
Столько всего уже сделать можно - просто не знаю за что и браться :)
Ну как, получилось?:P