| |
|
|
| | создал табличную форму в проекте(SQLExpress на отдельном сервере, связь по локальной сети), на ней сделал 3 комбобокса, которые получают данные из хранимых процедур, параметрами для хп являются предыдущие комбобоксы.
Вопрос следующий:
раньше в настольном приложении для сохранения данных я просто в СВОЙСТВАХ ФОРМЫ--> ДАННЫЕ--> устанавливал ИСТОЧНИК ДАННЫХ и через него сохранял информацию, просто и удобно, в проекте тоже есть такая возможность. Но почитав форум, например
http://hiprog.com/forum/read.php?id_forum=1&id_theme=3737&page=3,
я вижу , что предпочтителен другой способ сохранения данных.
Вопрос: вы сами каким способом сохранения данных пользуетесь при работе с сервером? | |
| |
| |
| |
|
|
| | не понял про какок хранение данных идет речь.
Данные будут храниться на SQL сервере | |
| |
| |
| |
|
|
| | да, данные хочу сохранять на сервере, находящемся в сети, в SQLServere | |
| |
| |
| |
|
|
| | Ну так и используйте возможности самого СКЛ сервера ( хранимки, функции ), либо же возможности акса. Тут ,как говорится, кому что нравится.
Тока настоятельно не рекомендую использовать конструкции типа
CurrentProject.Execute "Update Tbl1 блаблабла WHERE Tbl1.NameField="&me.TextBox1.Value.
Правильнее будет даже сказать - нельзя использовать такие конструкции, хотя они и работоспособные. | |
| |
| |
| |
|
|
| | для получения данных для последнего комбобокса я использую следующее:
Me.cbo_ShippedAdress.RowSource = "exec " & Chr(34) & "sp_ShippAdress" _
& Chr(34) & " " & Chr(34) & Me.cbo_customers & Chr(34) & "," & Chr(34) & Me.cbo_ShippedDate & Chr(34)
Me.cbo_ShippedAdress.Requery
Вот каков был смысл вопроса: насколько МУДРО и РАЗУМНО в проекте ADP при условии, что SQLServer находится на удалённм сервере, сохранять данные просто через
СВОЙСТВА ФОРМЫ--> ДАННЫЕ--> ИСТОЧНИК ДАННЫХ , при условии, что работать одновременно будут несколько человек с одной таблицей (куда вносятся данные). Будет сильно тормозить или вообще так делать нежелательно? | |
| |
| |
| |
|
|
| | По идее все должно нормально работать. Хотя я такую конрукцию никогда не использовал.
Несколько человек, посылающих одномоментно запросы на сервер - это не нагрузка. Тормоза возникнут при одномоментном запросе нескольких десятков тысяч человек. Но , думаю, вам это не грозит. | |
| |
| |
| |
|
|
| | Спасибо ,Мюллер, но опять повторю (получение данных через ХП меня не сильно беспокоит,пока) , меня беспокоит то, что одновременно к одной и той же таблице будут подключены и будут вносить в неё изменения несколько человек. И всё это будет происходить по-старинке: СВОЙСТВА ФОРМЫ--> ДАННЫЕ--> ИСТОЧНИК ДАННЫХ (в источник данных и вносятся данные) | |
| |
| |
| |
|
|
| | Я так и не понял что именно вас беспокоит. Работать оно будет. Сохраняться будут последние внесенные изменения. Они же и будут источником данных для формы.Один это человек внесет или несколько - не имеет значения. Еще раз повторюсь. Сохраняться будут последние внесенные изменения. Если работает одновременно несколько человек, то тот кто последним внес данные, тот и король. Т.е. его данные и будут источником для формы. | |
| |
| |
| |
|
|
| | Хорошо, тк людей немного может сделать несколько отдельных таблиц(по одной для каждого) для источника записей , а для совместной работы использовать Вьюшку или ХП из этих таблиц.
Кстати, ранее я неправильно написал
СВОЙСТВА ФОРМЫ--> ДАННЫЕ--> ИСТОЧНИК ЗАПИСЕЙ (надо было) | |
| |
| |
| |
|
|
| | В корне не верный подход. Доступ пользователей к таблицам делается в соответствии с ролями.
Хотя механизмы доступа к данным и запись данных диктуются исключительно бизнес-логикой поставленной задачи и, возможно, в вашем случае это приемлимо. Я ведь не знаю вашей задачи.
Но тем не менее, логика ,при которой для каждого пользователя создается своя таблица в подавляющем большинстве задач не приемлима. | |
| |
| |
| |
|
|
| | Вот. Буду знать. Может смогу уменьшить количество ошибок. Просто многие форумчане, которые разбираются в вопросе, используют в своей работе конструкции типа:
ADODB.RECORDSET и тд. для работы с бд., а не как я прямое подключение к таблице из свойств формы. Для настольного приложения этого было достаточно. Поэтому я и волнуюсь, что если с самого начала этого не понять, то потом будет ещё сложней и хуже | |
| |
| |
