| |
 20 Кб. |
|
| | Всем привет
Подскажите пожалуйста как правильно (что бы все работало и сам не запутался) связать одну таблицу с несколькими. Слышал в SQL-сервере есть триггеры, но пока я его не знаю и делаю на Access.
Связь нужна для защиты от пользователей (что бы не было потерянных записей ) Типа заголовок есть а данных нет и наоборот.
Либо пошлите на нужную ссылку 
Надеюсь пример понятен  | |
| |
| |
| |
|
|
| | Нужно разъяснение.
Это вы про то что в таблице tblAdresses есть запись, но для нее нет записей в btlBase? (например A0202) ? | |
| |
| |
| |
|
|
| | Нет
я про таблицы, соответствующие каждой операции
в tblOperation они прописаны (чуть-чуть)
как их корректно связать с tblBase  | |
| |
| |
| |
|
|
| | про таблицы, соответствующие каждой операции |
непонял  | |
| |
| |
|
|
| |
|
|
| | Вроде дошло 
Боюсь что для пустых "шапок" только на уровне форм.
поскольку "шапку" придется сохранить до того как будут добавлены остальные записи.
т.е. условие на уровне таблиц работать не будут.
А вот запретить добавлять записи без шапки вполне возможно, и вроде у вас это сделано, целостность данных вроде установлена | |
| |
| |
| |
|
|
| | В общих чертах понял
Заведу уборщицу "тетю Фросю" будет при старте базы порядок наводить или при закрытии.
Есть еще вопрос,
каким образом проверять количество в адресе
что бы обрабатывать списание из адреса
к примеру в адресе товара 20 шт., а пользователь пытается внести данные больше чем 20 шт, либо
один пользователь перемещает с адреса в другой адрес,а другой пользователь в это время выдает со старого адреса????  | |
| |
| |
| |
|
|
| | Лучше проверять при каких либо действиях пользователя...
а то пользователь заведет "шапку" и закроет базу, а "тетя Фросю" эту запись удалит т.к. нет подчиненых, и пользователь будет искать...
мне ваша предметная область не совсем понятна, "адрес" "количество", добавляйте к этому еще и название полей и таблиц. Так будет понятнее поскольку базу я вижу.
Проверять можно функцией dcount или dlookup или свою написать с использованием recоrdset, если проверять непосредственно перед сохранением, то вероятность что переместят на другой адрес несуществующее кол-во или отдадут больше чем есть на этом адресе будет стремиться к нулю.
поскольку время сохранения записи значительно меньше чем время просмотра записи юзером | |
| |
| |
|
|
|
|
