Можно обратиться к собранию с таким вопросом по разработке
Прошу внимательно посмотреть и ответить на вопросы
по подробней, ну как это делает Владимир Маскимов
(надеюсь никого не обидела)
Мне на периферии многая литература недоступна
Доступен интернет
Все возможные топики по этому форуму,
по другим фоксовским посмотрела
Скачала приложении клиент-сервер с этого сайта
Но тем не менее сохраняется много вопросов
Суть проблемы такова:
Работаю в небольшой конторе
Хватало локальных баз даннных
Теперь решили обзавестись локальной сетью
(Может это кому то покажется странным в 21 веке, но тем не менее)
Сеть будет одноранговая, ну может в ближайшем будущем с сервером.
Но денег(и желания у начальства) на MSSQL-сервер нет,
ну может быть в далёком будущем
Начальство прослышало о технологии клиент-сервер
Для начала необходимо создать программу файл-сервер
Вообще прочитала, конечно, что сервер можно сделать и на
Фоксе для начала(и понимания процесса)-так стоит ли этим занятся, и самое главное как?
Прочитав топики по нету, узнала, что далее безболезненный переход
на MSSQL-сервер из Фокса возможен только работая с представлениями
Статью Джима Фалино читала
Вообще такая привычка работать вдолбилась-окружение формы, там таблицы, фильтры, "старые команды" APPEND RECORD итд.
С представлениями вообще не работала, в смысле
с удаленными, как это рекомендует Фалино
(Цитата:Для форм ввода данных я рекомендую использовать удаленные представления)
Да, представления локальные использовала, ими обновляла
таблицу итд

Как я понимаю на сервере(и при файл-сервере, и при клиент-сервере)
находяться таблицы, на рабочей станции их нет
Подскажите как организовать :
1)Ввод, редактирование,удаление данных на уровне формы
Как быть с ключами?
<font color="red">И все это на удаленных представлениях?</font>
Как это все проделать-можно показать
<b><FONT COLOR="red"> на понятным примере</FONT></b>


Особенно мне не понятно выделенное красненьким ниже место
Как передать данные отредактированного курсора обратно в
представление, а потом в таблицу?

ЦИТАТА:
Дополнительный слой был бы реализован в форме курсора, открытого на чтение и запись с той же самой структурой и содержимым, что и курсор, полученный при использовании представления.
Затем объекты можно привязать к источнику при сохранении возможности манипулировать курсором, перед тем как представить информацию пользователю. Процесс выглядел бы примерно так:
Procedure Load
* Для этого теста открываем форму с данными
Use vOrders In 0
* Получаем копию результирующего набора
Select * from vOrders Into Cursor cOrders1 NoFilter
* Делаем копию cOrders1, открытую только на чтение
Use (DBF()) In 0 Again Alias cOrders
* Закрываем временных read-only курсор
Use In cOrders1
*
* Теперь, когда сработают методы Init
* объектов формы, привязанных к cOrders.
* Область с именем cOrders будет основной для работы формы
EndProc
<font color="red">Теперь можно работать с формой как обычно. При сохранении данных передайте данные отредактированного курсора обратно в представление и выполните TABLEUPDATE.</font>
Все что мы говорили выше про использование представлений, по-прежнему имеет место, мы просто добавили один дополнительный слой. При работе с небольшими результатами, это нормальное требование для систем клиент-сервер и скоростью обработки, которую обеспечивает Visual FoxPro, использование этого слоя не даст какого-то замедления работы.
Возможность манипулировать данными перед представлением их пользователю дает вам комбинацию преимуществ от использования свободных и привязанных объектов. Вы получаете средства внесения дополнительной функциональности, такие как поддержка различных валют, множества языков, в общем, всего того, что позволяет получить из "сырых" данных то, что ожидает пользователь.

2)Как реализуется механизм работы с данными-архивирования, упаковки, итд
можно это сделать с рабочих станций-в приложениях такого типа.
Вообще у меня открывается контейнер баз, таблицы экклюзивно, а затем
в папку "резерв" копируется архив папки "DATA"
Наверно папка дата должна быть на сервере, что логично

3)Выбор из справочников ,как я поняла лучше
не применять комбобоксы(источник-поля из алиаса),а ставить
текстбокс-рядом кнопка-вызов другой формы справочника.
В форме справочнике по клику например "выбор" как вставить??
REPLACE- понятно, а наверно надо INSERT.
Как это сделать?
4)отчетность-лучше тоже использовать таблицы-SQL-курсоры-экспорт
в приложения Office и тд, или как лучше.
сейчас я делаю именно так.

Если к примеру Вы скажете, что представления используй локальные, не морочь голову, то возникает вопрос:
1)-делать их в дизайнере, там ставить обновляемые поля, все это хранить в .dbc. А .dbc у нас на сервере!
Или как рекомендует Фалино
Цитата:
Шаг 5 - Храните представления в отдельной БД, чтобы не зависеть от сервера.
Это как??!!
то есть на рабочей станции поставить еще одну .dbc?
2)Делать CREATE SQL VIEW итд, а потом ручками устанавливать редактируемые поля итд. что необходимо.
В этом случае как обновить, добавить запись в таблицу, если можно пример.

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

Я далеко не волк, но все же ...
Вопросы:
1. "Контора небольшая" - сколько планируете соединить компьютеров?
2. Какой объем записей в таблицах предполагается?
Почему спрашиваю? Клиент-сервер это "круто", но имеет смысл, если надо потрошить на сервере огромные таблицы, а клиентов - десятки.
Часто можно обойтись простыми (free) таблицами с буферизацией - и скорость приличная и клиенты счастливы ;)))

Файл-серверная технология и клиент-серверная технология - это две большие разницы Это 2 сильно отличающиеся идеологии программирования.

Я бы очень не советовал делать нечто "универсальное", чтобы легко можно было переключиться из файл-серверного приложения в клиент-серверное.

Собственно FoxPro - позволяет строить файл-серверные приложения с минимальными изменениями по сравнения с однопользовательскими (локальными) приложениями.

Строго говоря, при файл-серверной технологии ты работаешь с базами данных и таблицами практически также как если-бы они лежали у клиента.

Отличия заключаются лишь в том, что все таблицы и базы данных следует открывать с опцией SHARED (или при настройке SET EXCLUSIVE OFF) вследствии чего становятся недоступными ряд команд (PACK, INDEX и т.п.), а также следует предусмотреть разрешение конфликтов совместного доступа - это когда 2 пользователя одновременно исправляют один и тот же документ.

Фактически, относительно небольшими усилиями можно переделать однопользовательское приложение в многопользовательское (если речь идет о файл-сервере), но вот переделать в клиент-сервер - это потребует значительно больших усилий.

По поводу статей:

Следует обращать пристальное внимание на дату написания, поскольку приведенные советы могут исходить из низкой надежности того или иного метода в ранних версиях FoxPro.

Кроме того, авторы имеют в виду как правило не некий "общий случай", а вполне конкретную рабочую ситуацию, которая вероятно в вашей задаче и не требуется.

Ну и совет общего плана: читать статьи следует с оглядкой - доверяй, но проверяй. Иногда там такое встречается, что непонятно, о чем автор думал, когда это писал

Спасибо за внимание.
Равилю:
Машин штук 15-20
Таблицы-есть по 100тыс.-справочники,
данные- за год добавление по 10 тыс.

Владимир мастер объяснений!
Тогда:
Не будем решать задачи на 10 лет вперед, будем по мере поступления.
Сто раз говорили-не беги вперед паровоза!
Как поставять сервер, так и спросим.
Но все таки:
И как же все-таки-таблицы или представления(по ответу я понял локальные)
обновляемые
Вопросы остались:
>Подскажите как организовать :
1)Ввод, редактирование,удаление данных на уровне формы
Как быть с ключами?
И все это на удаленных представлениях?
Как это все проделать-можно показать
на понятным примере
Добавить в окружение формы сделанное дизайнером лок. предст-е
Разрешение на обновление полей "получено"
Проверяла
Попробовала с разными буферизациями вьюшек, не обновляют таблицы
при редактированиии, добавлении записи...
Можете кусочки "секретного кода?"

Давайте сначала определимся в какой идеологии Вы будете создавать свое приложение: файл-серверной или клиент-серверной. Это принципальная разница.

Далее ответ исходя из предположения, что речь идет о файл-серверной технологии:

>>1)Ввод, редактирование,удаление данных на уровне формы

А как Вы это делали в однопользовательском приложении? В файл-сервере все абсолютно также. В этом случае нет никакой разницы где <b>физически</b> находится таблица, Вы работаете с ней так, как будто она лежит на машине клиента.

Исключением является ситуация, когда Вы работаете не напрямую с таблицей, а с Local View, да и то, не во всех случаях.

>>Как быть с ключами?

Тут вопрос в том, как именно у Вас генерится значение этого ключа. Возможны 2 варианта решения:

1) При создании новой записи во View можно вызвать функцию генерации ключа и присвоить сгенеренное значение новой записи во View.

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

2) Вызов функции генерации уникального ключа повешен на Default ключевого поля исходной таблицы и во View при создании новой записи недоступен.

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


Вообще-то, для начала неплохо бы определится с какой целью используется это самое Local View.

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

Использовать <i>обновляемое</i> Local View имеет смысл во вполне определенной ситуации: Когда Вы редактируете список документа именно как список, например, список позиций счета-фактуры

Как правило, в таких случаях нет никакой необходимости знать значение ключевого поля именно View, достаточно быть уверенным, что оно будет уникальным.


Что-то несколько корявое объяснение получается Впрочем, это всегда так, когда нет конкретного вопроса. В данном случае, как и в большинстве других надо просто попробовать. Тогда многие вопросы отпадут сами собой, а о других хоть будет понятно о чем спрашивать.

Т.е. просто попробуй создать Local View и прикинь для каких целей оно тебе понадобиться. Сразу станет ясно о чем спрашивать и нужно ли спрашивать вообще?


По поводу добавить View в DataEnvironment

Ну собственно процесс добавления ничем не отличается от процесса добавления таблицы базы данных, только когда появится список таблиц, следует установить переключатель в разделе Select с Tables на Views.

Особенность заключается только в случае использования параметризированных View. В этом случае, чтобы при открытии формы не возникал запрос на ввод значения параметра View в свойствах View в DataEnvironment следует установить значение NoDataOnLoad=.T., а в методе Init-формы следует задать значение параметра и выполнить перезапрос View, примерно так:

LOCAL ParamView
ParamView=1
=ReQuery("MyLocalView")



По поводу обновления информации в исходных таблицах, если было изменение во View.

В дезайнере View необходимо сделать минимум следующие настройки на закладке Update Criteria

-) Поставить "птичку" в "Send SQL Updates" (в левом нижнем углу)
-) Выбрать ключевое поле или поля в столбце, заголовок которого помечен значком ключа
-) Выбрать поля, изменения в которых будут сброшены в исходную таблицу проставив птички в столбце заголовок которого помечен значком карандаша.

Любое View открывается в режиме оптимистической буферизации и никак иначе. По умолчанию в режиме буферизации строк (3), но можно переключить и в режим буферизации таблицы (5)

Сброс буфера (изменений) из View в исходные таблицы происходит

В режиме буферизации строк

-) При переходе на другую запись
-) При закрытии View
-) По команде TableUpdate()

В режиме буферизации таблиц

-) Только по команде TableUpdate() и никак иначе

При этом следует иметь в виду, что если исходные таблицы также находятся в режиме буферизации, то сброс произойдет не в собственно таблицы, а в их буфер. Для окончательной записи в исходные таблицы в этом случае необходимо дать команду TableUpdate() еще и на исходные таблицы.

Три года назад, когда начинали новый проект, было выставлено условие, что база данных должна быть только на Fox-е. Понимая, что со временем она вырастет, и Fox ее тянуть не сможет, мы должны были разаботать такой стиль программирования приложений, которая позволит лекго перейти на клиент-серверную технологию. Причем, клиентом останется VFP, а сервером станет MS SQL. Так и вышло. Через 2 года база разрослась до 1.5 Гб. Некоторые таблицы имели до 2 000 000 записей. Пользователей стало 2 десятка. Вот тогда мы и начали веревод базы на SQL. Нам это удалось достаточно легко, т.к. при создании БД на VFP и приложений были жестко применены следующие основные принцыпы.
1. База строилась как реляционная. Именно база VFP, а не свободные таблицы. База сначала размещалась на одной из рабочих станций одноранговой сети. Потом ее выложили на файл-сервер для общего доступа. Каждая таблица базы имела все необходимые индексы по условиям запросов. Все индексы простые (не составные). Каждая таблица имела уникальное автоинкриментальное поле и индекс на него (база строилась на VFP 6.0, за это поле отвечала хранимая процедура). Поля для связи в дочерних таблицах назывались также, как и родителькая таблица с префиксом Id, на которые также имелся индекс. Категорически не рекомендую использовать для таких полей тип char, т.к. потом при переносе базы на SQL могут возникнуть проблемы с индексацией (при стандартной установкой SQL не видит различий больших и малых букв). Каждая таблица имела индекс с выражением deleted() .Тригеры на целостность не строили, выигрывая в производительности. За целостностью должны были следить приложения. Потом на SQL для контроля целосности установили констрайны. Но так как в данные приходилось вмешиваться рученками, потом помучались.
2. Все общение с данными приложения строили ТОЛЬКО с помощью хранимых в БД VFP процедур, которые вызывались из форм приложений с нужными параметрами и которые или выносили какой-нибудь запрос в курсор, построенный с использованием команд SQL, или делали изменение/вставку/удаление также с использованием команд SQL (VFP разумеется). При небходимости, в приложениях устанавливались транзакции для изменения данных пакетом или блокировки . После отработки какой-либо формы приложение вычищало из рабочей области все свои курсоры и используемые таблицы БД. Что обеспечило устойчивость БД. За 2 года база ни рабу не упала.
Все это и обепечило быстрый переход на клиент-серверную технологию.
Подняли данные на SQL из него же мастером, построили индексы, какие были на VFP, добавили нужные составные индексы, которые в VFP в запросах все равно не использовались, построили констрайны.
Пенесли хранимые процедуры (T-SQL и команды SQL VFP очень схожи, правда у T-SQL возможностей побольше). Ну и, естественно, подрулили приложения в части вызова хранимых процедур теперь с SQL и организаций транзакций и блокировок, которые тоже стали на SQL.
А теперь ловим кайф. Скорость запросов OLAP выросла в десятки раз. Да и OLTP изменения выполняются гораздо быстрее. Правда база растет очень быстро. За год уже 2-й сервер (2 х Xeon), причем только под SQL. Сейчас думаем о замене сервера на 4 x Itanium. Сейчас база 100 таблиц, 2 Гб, некоторые таблицы до 3.5 млн записей.

MSDE идет в стандартной поставке VFP. Так что не бойтесь. Кусочки кода есть в этой книге
http://www.just4thai.com/vfp_howto/files/book_CS.zip
Если конечно с аглицким проблем нет

Владимир вам давно пора написать свой VFP Hackers Guide... Наверняка неплохо бы продавался

Спасибо за проявленное внимание и понимание ""неопытной женщины""(:о)))
-Насчет ключевых полей
У меня в дефаульт-валюе первич. ключа поля таблицы стоит вызов процедуры
(алгоритм обычный-есть фри таблица-поля таблица, последний номер записи)
при добавлении записи, +1, возвращается значение из этой таблицы
Может быть в представлении вовсе обойтись без "мороки" с ключевыми полями. Пойдет сброс буфера в таблицу, там и "сгенериться" ключевое значение

Добавление, редактирование записей идет по алгоритму визарда
(непомню как класс называется в визарде, но когда генеришь форму визардом(чего я уже давно не делаю :о) там есть радиокнопка-"графические кнопки")
(или еще подкорректированный код из Горева)
Про свойства этого кода, которые не описала наверно поймете
* Добавляем запись
IF This.Parent.lEditing = .F.
* Пытаемся найти удаленную запись
SET DELETED OFF
LOCATE FOR DELETED()
IF FOUND()
* Снимаем отметку на удаление
RECALL NEXT 1
ELSE
* Если не нашли, добавляем
APPEND BLANK
ENDIF
SET DELETED ON

ThisForm.Refresh()
This.Parent.cmdEdit.Click()
* Сохраняем запись
ELSE
* Проверяем наличие буферизации
IF CURSORGETPROP("Buffering") > 1
= TABLEUPDATE()
ENDIF
*записываем дааные даты в таблу
FOR nFieldNum = 1 TO FCOUNT()
IF FIELD(nFieldNum) = "TIMESTAMP"
REPLACE timestamp WITH DATETIME()
ENDIF
ENDFOR

*modifik-записываем данные о модификаторе записи

IF TYPE('modifik')#"U"
REPLACE modifik WITH STR(usercod)
ENDIF


This.Parent.lEditing = .F.
This.Parent.disableall
ThisForm.Refresh
This.Parent.Buttonrefresh
* Активизируем клавишу перехода к следующей записи
This.Parent.cmdNext.SetFocus()
ENDIF




* Переходим к редактированию данных
IF This.Parent.lEditing = .F.
This.Parent.enableall
* Ищем первое текстовое поле и активизируем его
FOR I = 1 TO ThisForm.ControlCount
IF ThisForm.Controls(I).Name = [txt]
ThisForm.Controls(I).SetFocus
EXIT
ENDIF
ENDFOR
* Отменяем сделанные изменения
ELSE
* Проверяем наличие буферизации
IF CURSORGETPROP("Buffering") > 1
=TABLEREVERT()
ENDIF
* Возвращаемся к предыдущей записи
GO (This.Parent.nSaveRecNo)
This.Parent.lEditing = .F.
This.Parent.disableall
ThisForm.Refresh()
This.Parent.Buttonrefresh
* Активизируем кнопку перехода к следующей записи
This.Parent.cmdNext.SetFocus()
ENDIF

С вьюшками этот код работает только на редактирование, на добавление, не хочет

Для Сергея-почти все что у Вас описано, так и делается
>>или делали изменение/вставку/удаление также с использованием команд SQL (VFP разумеется).
Вышеприведенный код как римерно под это поредактировать.
прошу прошения что нагружаю вас кодом, конечно нужно самой сесть разбираться(что я конечно буду делать), но боюсь "уйти из он-лайна"
(На этом форуме темы быстро уходят из внимания)

Спаибо заранее за ответ

ой