forum.clarionlife.net

talgat55 писал(а): ↑10 Январь 2024, 11:02 так можно заполнить что-нить Сохранить Открыть и продолжать
Оператор ленивый и лишних движений не хочет делать...

Так это все автоматом и делается. У меня два десятка дочерних таблиц. Смысл заполнять дочерние записи, если первичная запись не сохранилась в БД. Для SQL это,увы, бывает какая-нить ошибка сервера или доступа и т.д.

и где он такой шаблон...

talgat55 писал(а): ↑10 Январь 2024, 16:10 и где он такой шаблон...

На фтп в составе других наборов: и в ABC-chain тоже есть

Вы покажите как выглядит форма с этой кнопкой. Мне непонятно как объяснить пользователю, что для ввода других данных нужно сначала нажать на эту кнопку. А что будет если сначала нажать на эту кнопку, а потом отказаться от редактирования. Запись останется?

finsoftrz писал(а): ↑10 Январь 2024, 14:59 В MS SQL это называется SCOPE_IDENTITY(), насколько помню.

Так и есть. Жутко неудобный механизм. Поэтому для MS SQL нужно либо воспользоваться "/AUTOINC", "/PREAUTOINC", "PROP:ServerAutoInc", либо функцией newid (но она делает идентификатор нецелочисленный, а uniqueidentifier, фактически строка в 36 символов).

kreator писал(а): ↑10 Январь 2024, 17:02 Вы покажите как выглядит форма с этой кнопкой. Мне непонятно как объяснить пользователю, что для ввода других данных нужно сначала нажать на эту кнопку. А что будет если сначала нажать на эту кнопку, а потом отказаться от редактирования. Запись останется?

Добавление записи: После заполнения обязательных полей и нажатия на Применить: Запись останется. Отказываться от редактирования (Cancel) раньше надо было до нажатия Применить
В дальнейшем редактирование записи стандартно.

"Применить" + "Отмена" = "Ок"? Так себе решение. Как по мне - откуда из прошлого века, когда всё было впервые и вновь. Даже то, что надо все формы переводить на эти кнопки, уже не катит.

kreator писал(а): ↑10 Январь 2024, 19:53 "Применить" + "Отмена" = "Ок"? Так себе решение. Как по мне - откуда из прошлого века, когда всё было впервые и вновь. Даже то, что надо все формы переводить на эти кнопки, уже не катит.

Скорее, последнее. Тоже был большой диспут на эту тему, как раз те, кто работал с sql, рекомендовали не создавать запись на сервере сразу. Мне кажется, что оба варианта имеют право на жизнь. Возможно, двухэтапное сохранение более корректное, а создавать сразу запись в базе данных с незаполненными обязательными полями это легаси подход. Примерно, как некоторые рекомендуют открывать запись на редактирование всегда в режиме read only, а потом включать возможность редактирования специальной кнопкой в форме (как сейчас в 1с8 реализовано). Но кто же будет переделывать, по другому тоже работает, все привыкли...

kreator писал(а): ↑10 Январь 2024, 17:49 Поэтому для MS SQL нужно либо воспользоваться...

привязка конкретно к MSSQL?
Сейчас все делаю на mysql, c учетом неизбежности Web-доступа и возможности использования в линуксах.

kreator писал(а): ↑10 Январь 2024, 19:53 Даже то, что надо все формы переводить на эти кнопки, уже не катит

Какие все? В данном случае это две "главных" формы абитуриент/студент. Остальное - это дочерние формы или формы справочников

morkovin писал(а): ↑11 Январь 2024, 8:07 Какие все? В данном случае это две "главных" формы абитуриент/студент. Остальное - это дочерние формы или формы справочников

Я не про Ваше. А, например, про своё. Есть 1000+ форм с кнопками "Ok" и "Canlel". И тут появляются одна-две с кнопками "Apply" и "Cancel". Нормально? Как по мне, то ненормально.

morkovin писал(а): ↑11 Январь 2024, 7:58 привязка конкретно к MSSQL?

Ну да. Как для Firebird можно сделать я написал. На самом деле это очередной костыль (вот это т.н. "бронирование ID-шника"). Если делать базу по уму, то должны быть внешние ключи, например. Соответственно, чтобы добавить дочернюю запись, родительская должна физически существовать.
Я не вижу никакого криминала в том, что "пустая" запись будет создана на сервере при входе в форму. Времена когда сеть недоступна или локальная станция зависла безвозвратно ушли. Я вот в начале нулевых перевёл большую базу с tps на SQLAnywhere. Причём драйвер SQLAnywhere (не помню уже какая версия Клариона была, наверно 5.0) не работал с существовавшим сервером, пришлось использовать ODBC. Поменял только тип драйвера в словаре для таблиц и всё. Постепенно стал переносить функционал на сервер, но автонумерация так и осталась на клиенте. Всё работает больше двадцати лет, проблем нет. Позже была попытка перевести на прямой драйвер. Он конечно дико удобней и эти свойства (о которых я написал) в "кассу". Дело не пошло. Уже клиенту ничего не надо. Всё так и помрёт. Поэтому Талгату советую не париться, оставить всё как в tps.

morkovin писал(а): ↑10 Январь 2024, 16:23 и в ABC-chain тоже есть
TwoEtap.tpw

а файл .TPL для него какой?

не нужен tpl файл. Шаблоны могут быть как в tpl так и в tpw. В чём разница непонятно.

kreator писал(а): ↑11 Январь 2024, 15:30 не нужен tpl файл

нужен - он главный, его регистрируют и в нем идет инклуд tpw

Поэтому, добавь в любой TPL инклуд для tpw

ingasoftplus писал(а): ↑11 Январь 2024, 15:43 нужен - он главный, его регистрируют и в нем идет инклуд tpw