Вопрос наверно глупый но я застряла...
Как обновить ремоут виев при модификации структуры удаленной базы?
То есть если я меняю структуру удаленной базы, то как мне не пересоздавая в Фоксе ремоут виев просто его обновить его? Или все же надо его пересоздать?

А что подразумеваешь под "обновить"? Уборать/добавить поля или что?

Цитата:

Или все же надо его пересоздать

нужно. либа генери прогу через GenDBC, оттуда выдирай кот своего вьшника и ручками создай через CREATE VIEW новый

Цитата:

Уборать/добавить поля или что

Да, в том числе добавление\удаления ограничений

Цитата:

либа генери прогу через GenDBC, оттуда выдирай кот своего вьшника и ручками создай через CREATE VIEW новый

Стоп. И так каждый божий раз?
Ты хочешь сказать что при любом изменении структуры удаленной базы, удаление\добавление поле, изменения связей, ограничений и тому подобное, надо пересозадвать ремоут виевы заново? А я думала может есть что нибудь наподобе РЕФРЕШЬ РЕМОУТ ВИЕВ и жизнь становиться легче....

Делаешь свою мульку RefreshRemoveView() со фсякими разными параметрами и наслаждаешься. Это те щаз страшно переделывать представления, потому шта Оракл небось содержит тока парочку таблиц и связь одну ;) А вот когда их будет немеряно, то што-бы в самом Оракле изменить структурку - подумаешь сперва - ибо менять живые данные с констрейнами на сервере БД это прастите хуже киросину

Цитата:

Делаешь свою мульку RefreshRemoveView() со фсякими разными параметрами и наслаждаешься

Уговорил
Сделаю как насоветовал ;)

поготь!! может што-нить другое есть еще

Я не делаю RV в построителе. Одно RV - один PRG модуль с CREATE VIEW ...

Цитата:

Одно RV - один PRG модуль с CREATE VIEW

Ну так потом же все равно прийдеться менять параметры CREATE VIEW чтобы пересоздать RV, тем более надо будет удалить старый.....я правельно понимаю?

Конечно нужно будет перезапустить PRGку отвечающую за данное RV. Удалять RV не надо пересоздаешь прям поверх.

Цитата:

Удалять RV не надо пересоздаешь прям поверх.

Он перезапишет?

Цитата:

Конечно нужно будет перезапустить PRGку отвечающую за данное RV

Тогда надо как то анализировать изменения, чтобы перезапускать prgшку
К примеру кто то подконекктился к удаленной базе сделал изменения и уведомил....Народ начинает работать и соответсвенно лезут ошибки....Не буду же я ее каждый раз автоматом перезапускать...

Цитата:

Он перезапишет?

А куда он денется!

Цитата:

кто то подконекктился к удаленной базе сделал изменения и уведомил

У вас что изменения в структуре делает кто попало?
Обычно за это дело отвечает IT отдел, он же и вносит исправления во всё остальное.
Если бы ты пользовалась не RV, а просто посылала запрос через SQLEXEC() ты конечно бы сделела соответствующие правки под новую структуру данных

Через SQLEXEC( ) мне итак все понятно У меня есть написанное небольшое приложение именно с SQLEXEC()
А вот с RV немножко в луже сижу

Цитата:

Обычно за это дело отвечает IT отдел, он же и вносит исправления во всё остальное

Ну у нас он и отвечает... ПРосто всякое бывает охота перестраховаться от всяких экцессов

Божья_коровка
ПРосто всякое бывает охота перестраховаться от всяких экцессов

За такие эксцессы у нас можно с работы вылететь. Я имею ввиду несанкционированное изменение структуры базы.

Сам я по этой причине RV и не пользую потому как на этапе внедрения часто приходится менять структуры у заказчика. Хотя если бы меня прижало именно с RV то я бы их программно создавал в начале работы проги. А для того что бы не зависеть от изменной струкуры написал бы так
Указав только ключеное поле - остальные поля автоматом становятся updatable
Хотя что толку от этого - в формы все равно надо добавлять новые поля, так что переделка EXE неизбежна

Цитата:

За такие эксцессы у нас можно с работы вылететь. Я имею ввиду несанкционированное изменение структуры базы.

У нас тоже, а толку? Человек вылетит а проблема останеться У нас и базы рабочие удаляли, было дело, стажеры немножко ошиблись и удалили рабочую базу. Им за это по башке, а толку то, базу этим не восстановишь ЧЕловеческий фактор присутвует везде

Цитата:

ЧЕловеческий фактор присутвует везде

здесь русский дух.. здесь дУхом пахнет

Hi Божья_коровка!

Ограничения, индексы, триггера и т.п. НЕ требуют пересоздания представления.
Только изменения в полях, КОТОРЫЕ УКАЗАНЫ в RV - т.е. если у тебя было RV
типа SELECT f1, f2, f3 FROM t1 - то всё что НЕ касается перечисленных полей
(удаление f4, добавление f5, изменение типа/размера f6) - проходит
незамеченным. Потому IMHO всегда стоит указывать именно список полей, а не
SELECT *
Кстати всё это в равной степени касается и локальных представлений.
P.S. Я практически не пользуюсь ViewDesigner, предпочитая программное
создание View-ов (и из-за ограничений/глюков дизайнера, да и просто так
обычно проще вносить изменения).

Игорь, а как же ограничения типа NOT NULL у поля?