Attain. Контроль ссылочной целостности. Или я чего-то не понимаю, или одно из двух:(

[Evgeniy]

Народ! Чего-то я не понимаю.
Ситуация: есть таблица country, есть таблица customer, в ней есть поле Country Code, в котором стоит ссылка на country. Выбираю страну, на которую ссылаются ряд клиентов и пытаюсь ее удалить. Она удаляется! При этом в этих клиентах повисает код удаленной страны, который ссылается ни на что. А где контроль ссылочной целостности? Может нужно просто что-то включить, что бы он заработал? (хотя я взял таблицы в стандартной демо-базе, там должно быть все настроено). Есть свойство TabkeRelation, в нем все прописано. Караул!!!!

[Evgeniy]

Нда... судя по тому, что меня никто не поправляет, это не я чего-то не понимаю, а там этого просто нет... Тогда... это тот случай, когда просто сказать нечего. Система стоимостью в несколько десятков килобаксов, разработчики которой трендят про клиент-серверную, а то и трехзвенную архитектуру, не поддерживает таких элементарных вещей... Это, ребята, несерьезно... Хотя я понимаю, конечно, что это адресовать надо не обитателям данного форума.

[Sharky]

Можно попробовать задать этот вопроси к непосредственно на
http://www.partnerguide.com/ , может что ценного и ответят
можно еще повесить на OnDelete и на OnModify тригера обработчики.....
типа, если грохается какая-то страна, то проверять есть у какого-нить клиента этот код.
Если есть, то прервать удаление....

Тоже самое с модификацей....

[Rungart]

Скорее всего, там ответят, что реализация подобного механизма отрицательно скажется на производительности БД. В общем, согласен с Sharky : спасение утопающих дело рук самих утопающих ...

[Evgeniy]

По поводу триггеров и спасения утопающих - это все понятно. Хотя насчет производительности это бред, т.к. скорость перебора таблиц в триггерах и поиска ссылок заведомо не может быть больше скорости поиска их на сервере. Дело-то не в этом. Дело в том, что любая серьезная клиент-серверная система просто должна поддерживать такие вещи,причем на уровне сервера. Есть же связь таблиц через tablerelation, есть механизмы контроля ссылочной целостности в SQL-server. Так почему же не привязать одно к другому? А потому что ломало писать. Сойдет и так, пипл схавает.
А писать туда смысла нет, они напишут какую-нибудь отписку про производительность или про то, что мы, мол, пошли своим путем.
И ведь что интересно: в описанном выше примере нет вообще никакого контроля, ни триггерами, ни чем-то еще... Просто нет, и все. Если что - проблемы пользователя. А ведь я взял первый попавшийся пример, причем самый простой. Ох, на нехорошие мысли все это наводит... Что же там окажется, если поглубже копнуть, интересно?

[Rungart]

Чем глубже в лес, тем толще партизаны. Как, говорится, "жди чудес". К примеру, штатными средствами удалить ошибочно примененные операции НЕВОЗМОЖНО. При этом служба поддержки сообщает, что изменений по этому поводу не предвидится. Вот так.

[Кактус]

Что ты имеешь ввиду?

[Sharky]

например:
Ты учел заказ, но понял. что ошибся в номенклатуре.......или в количестве...
Так вот: нельзя вернуть учтенный заказ обратно на редактирование, можно создать только корректирующий заказ и/или возврат.....
Вот так-то..............
Да, кстати, Navision позиционируется как система, открытая для разработок...пиши что хочешь.....
На текущий момент я видел уже парочку сторонних решений, есть вещи и лучше, чем стандартный кронус :-))))))))))))

[Rungart]

Я имел ввиду следующее:
К примеру, есть два счета по 100 каждый и одна оплата на 100. Применить оплату можно к любому из них. Т.е. при применении оплаты указывается какой из счетов будет закрыт. Если ошибочно применить оплату к первому счету вместо второго, то изменить это применение уже нельзя. Ну и, следовательно, механизм сроков оплаты, скидок оплаты, выставления процент нот и т.д. идет лесом.

[Sharky]

Абсолютно согласен!

[Grizzly]

Цитата:

Изначально опубликовано Evgeniy
Дело в том, что любая серьезная клиент-серверная система просто должна поддерживать такие вещи,причем на уровне сервера.

А причем здесь клиент-серверная архитектура? Архитектура системы и поддержка ссылочной целостности это абсолютно независимые свойства. Наличие одного из них не влечет за собой обязательность другого.

Цитата:

Изначально опубликовано Evgeniy
Есть же связь таблиц через tablerelation, есть механизмы контроля ссылочной целостности в SQL-server. Так почему же не привязать одно к другому? А потому что ломало писать. Сойдет и так, пипл схавает.

1. При определении свойства TableRelation могут использоваться очень сложные настройки, которые просто не могут быть реализованы с помощью стандартной функциональности SQL Server по поддержке ссылочной целостности.

2. Так как описание поведения таблиц производится стандартными средствами системы, в том числе на C/AL (тригеры таблиц), который не может быть интерпретирован на сервере БД (ни в SQL Server, ни в Navision Server), то вообще все действия по управлению таблицами производятся на клиенте.

3. Контроль ссылочной целостности должен производится прикладными программистами (через триггеры onModify, OnDelete и т.д.). Кстати, так в Attain и делается (слабо удалить клиента по которому есть операции?). Данный конкретный пример, на мой вгляд, это просто ошибка разработчиков.

[Grizzly]

Цитата:

Изначально опубликовано Rungart
Я имел ввиду следующее:
К примеру, есть два счета по 100 каждый и одна оплата на 100. Применить оплату можно к любому из них. Т.е. при применении оплаты указывается какой из счетов будет закрыт. Если ошибочно применить оплату к первому счету вместо второго, то изменить это применение уже нельзя. Ну и, следовательно, механизм сроков оплаты, скидок оплаты, выставления процент нот и т.д. идет лесом.

Учтенные платежи можно отменить через "Платеж. Книга Операций".

[Evgeniy]

Цитата:

При определении свойства TableRelation могут использоваться очень сложные настройки, которые просто не могут быть реализованы с помощью стандартной функциональности SQL Server по поддержке ссылочной целостности.

По-моему, они здесь не причем. Есть же свойство ValidateTableRelation и проверка "на лету" наличия вводимого значения в соответствующей таблице. Точно так же можно было реализовать и контроль ссыл. цел. Пусть на клиенте, это уже не так принципиально.

Цитата:

Архитектура системы и поддержка ссылочной целостности это абсолютно независимые свойства. Наличие одного из них не влечет за собой обязательность другого.

А по-моему, все-таки влечет. Даже не столько кл-серв. архитектура, сколько вообще претензия на большую серьезную систему. Не зря же все большие сервера БД (SQL server, oracle, sybase и иже с ними) это поддерживают. Но в общем-то это уже действительно вопрос философский. Просто из всех БД, которые я когда-либо видел, attain - это первая, которая позволяет пользователю влегкую произвести некое действие, которое нарушит целостность базы. А что касается ошибки - на мой взгляд, наоборот - для каких-то крупных узлов это прописали, а для всех мелких - оставили так.

[Rungart]

2 Grizzly :

Если можно, то pls, подробнее, как можно с правами пользователя отменить сложное применение оплаты к нескольким счетам.

[Grizzly]

Цитата:

Изначально опубликовано Evgeniy
По-моему, они здесь не причем. Есть же свойство ValidateTableRelation и проверка "на лету" наличия вводимого значения в соответствующей таблице. Точно так же можно было реализовать и контроль ссыл. цел. Пусть на клиенте, это уже не так принципиально.

В том то и дело, что на основании этих свойств из таблицы, которая ссылается, получить список возможных значений легко, достаточно выполнить все вычисления для текущей записи. А вот из таблицы на которую ссылаются - нет. Для этого нужно получить список всех таблиц, которые могут на нее ссылаться (т.е. содержат ее имя в пределении свойства TableRelation), затем на основании всех записей этих таблиц определить (вычислить) множество записей, которые реально ссылаются. Что в общем случае практически невозможно. Поэтому прикладной программист, зная природу этой связи, сам должен написать код, который наиболее оптимально обработает данную ситуацию.

Цитата:

А по-моему, все-таки влечет. Даже не столько кл-серв. архитектура, сколько вообще претензия на большую серьезную систему. Не зря же все большие сервера БД (SQL server, oracle, sybase и иже с ними) это поддерживают. Но в общем-то это уже действительно вопрос философский. Просто из всех БД, которые я когда-либо видел, attain - это первая, которая позволяет пользователю влегкую произвести некое действие, которое нарушит целостность базы.

Вообще-то Attain - это не СУБД, а прикладная система. А не использует эти возможности только потому, что ее модель данных не может быть представлена стандартными средствами промышленных СУБД. Она более сложная. Кстати, в Axapta, которая претендует на еще более серьезную систему, все обстоит точно также (на сервере ссылочная целостность не контроллируется). Во многих других подобных системах тоже.

Цитата:

А что касается ошибки - на мой взгляд, наоборот - для каких-то крупных узлов это прописали, а для всех мелких - оставили так.

Хорошо, пусть будет не ошибка, а халатность :-)

[Evgeniy]

Цитата:

В том то и дело, что на основании этих свойств из таблицы, которая ссылается, получить список возможных значений легко, достаточно выполнить все вычисления для текущей записи. А вот из таблицы на которую ссылаются - нет. Для этого нужно получить список всех таблиц, которые могут на нее ссылаться (т.е. содержат ее имя в пределении свойства TableRelation), затем на основании всех записей этих таблиц определить (вычислить) множество записей, которые реально ссылаются. Что в общем случае практически невозможно.

В общем да, резонно. Хотя с другой стороны, информация о структуре БД наверняка хранится в к-л служ. таблицах. Если они должным образом спроектированы, то список таблиц, ссылающихся на данную, должен по идее оттуда вытаскиваться легко. Не очень корректная аналогия, но та же в зубах уже навязшая 1С отслеживает же это как-то при удалении записи. Но вообще ладно.


Возник вопрос не по теме (отдельную ветку открывать не хочется):
Есть какой-то справочник, есть привязанная к нему форма. При вводе новой записи она записывается сразу, при вводе ключевого поля. Можно ли как-то сделать, чтобы сначала вводились все поля, а только потом запись сохранялась (или не сохранялась)? Есть конечно вариант сделать отдельную форму с тучей переменных, а потом записывать их значения в данную таблицу, но это как-то слишком... Может есть что-то проще? Если кто-то знает, просветите, плз.

[Rungart]

У формы есть свойство DelayedInsert

DelayedInsert
Use this property to have the system wait until the user leaves the record before it inserts the new record into the database. By default, the system inserts the new record when the user leaves the control that shows the primary key in the table.

[Evgeniy]

Вот за это спасибо! То что надо.

[Grizzly]

Цитата:

Изначально опубликовано Rungart
2 Grizzly :
Если можно, то pls, подробнее, как можно с правами пользователя отменить сложное применение оплаты к нескольким счетам.

Я погорячился :-)
Конечно, можно отменить отражение платежа в фин учете, но не его применение.

[chernikovd]

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