Имя таблицы как параметр запроса

← →
StriderMan © (2006-08-02 20:19) [0]

Нужно написать хранимую процедуру, которая будет работать сразу для нескольких таблиц.

Можно ли как-то передать в запрос имя таблицы?

← →
Anatoly Podgoretsky © (2006-08-02 20:28) [1]

Метаданные не могут использоваться в параметрах.
Хранимые процедуры не относятся к Дельфи и они зависят от сервера.
Так что тебе на форум по серверу.

← →
Megabyte © (2006-08-02 21:29) [2]

В MSSQL Server, например, есть такая возможность - это динамически формируемый(соответственно, с параметрами) на сервере запрос.

Все зависит от сервака!

← →
Anatoly Podgoretsky © (2006-08-02 22:40) [3]

Динамические запросы можно делать где угодно.
А вот сделать SELECT * FROM :tbl нельзя

← →
DrPass © (2006-08-03 01:39) [4]

> сделать SELECT * FROM :tbl нельзя

Непосредственно так нельзя. Но если сервером поддерживается execute statement в той или иной ипостаси, текст запроса можно сформировать динамически в самой процедуре, в том числе и из передаваемых параметров. Само собой, такие запросы не прекомпилируются, соответственно, еще нужно убедиться, что их использование подходит с точки зрения производительности

← →
StriderMan © (2006-08-03 08:51) [5]

сервер FireBird 1.5

← →
Johnmen © (2006-08-03 09:09) [6]

Уже сказали, execute statement. Добавлю - читать документацию...

← →
StriderMan © (2006-08-03 09:13) [7]

Всем спасибо, буду пробовать

← →
Sergey13 © (2006-08-03 09:15) [8]

ИМХО, лучше в процедуре сделать несколько веток в зависимости от параметра. Избавляет от постоянного разбора/перекомпиляции запроса сервером.

← →
PEAKTOP © (2006-08-03 09:22) [9]

CREATE PROCEDURE MY_REFERENCE( Q_TABLE_NAME VARCHAR(31) )RETURNS( ID INTEGER, NAME VARCHAR(100) ) AS DECLARE VARIABLE P_SQL_STMT VARCHAR(255); BEGIN IF(:Q_TABLE_NAME IS NULL)THEN BEGIN SUSPEND; EXIT; END P_SQL_STMT = "SELECT CAST(TB.ID AS INTEGER), TB.NAME FROM "||:Q_TABLE_NAME||" TB "; FOR EXECUTE STATEMENT :P_SQL_STMT INTO :ID, :NAME DO SUSPEND; END )

← →
Johnmen © (2006-08-03 09:32) [10]

> PEAKTOP © (03.08.06 09:22) [9]

В документации примеры лучше и их больше. С комментариями.

← →
StriderMan © (2006-08-03 12:22) [11]

> Sergey13 © (03.08.06 09:15) [8]
> ИМХО, лучше в процедуре сделать несколько веток в зависимости
> от параметра. Избавляет от постоянного разбора/перекомпиляции
> запроса сервером

Тогда проще в каждую таблицу ХП добавить.

← →
StriderMan © (2006-08-03 12:24) [12]

> PEAKTOP © (03.08.06 09:22) [9]

спасибо, попробую

> Johnmen © (03.08.06 09:32) [10]

посмотрю

← →
Sergey13 © (2006-08-03 13:12) [13]

> [11] StriderMan © (03.08.06 12:22)

1.ХП в таблицу не добавляют. ХП - это отдельный объект БД.
2.Дело твое.

← →
StriderMan © (2006-08-03 13:19) [14]

> Sergey13 © (03.08.06 13:12) [13]
> 1.ХП в таблицу не добавляют. ХП - это отдельный объект БД.

сорри, неверно сказал. Имел ввиду ХП для каждой таблицы

← →
Dok (2006-08-03 13:56) [15]

> Можно ли как-то передать в запрос имя таблицы?

А вчем проблема заюзать конкатенацию строк?
Query1.SQL.Text := "select * from " + TableName; Query1.Open();
Или Format?

← →
StriderMan © (2006-08-03 14:03) [16]

> Dok (03.08.06 13:56) [15]
> А вчем проблема заюзать конкатенацию строк?

вобщем-то так сейчас и работает. Но для совершения операции нужно сделать 4! запроса. Поэтому и пришла мысль переделать на ХП. а в ХП просто так не передашь имя таблицы. Буду пробовать Execute statement

← →
Dok (2006-08-03 14:12) [17]

> вобщем-то так сейчас и работает. Но для совершения операции
> нужно сделать 4! запроса. Поэтому и пришла мысль переделать
> на ХП. а в ХП просто так не передашь имя таблицы. Буду пробовать
> Execute statement

а зачем это все городить? задача?

← →
StriderMan © (2006-08-03 15:50) [18]

> задача?

у двух записи в таблице взаимно поменять значение уникального поля.

← →
Dok (2006-08-03 15:52) [19]

> у двух записи в таблице взаимно поменять значение уникального
> поля.

и? зачем тут ХП?

← →
StriderMan © (2006-08-03 15:55) [20]

> и? зачем тут ХП?

чтобы не кидать с клиента несколько запросов. а именно 4 штуки.

← →
Sergey13 © (2006-08-03 15:55) [21]

> [18] StriderMan © (03.08.06 15:50)

Очень странная задача. Если она постоянная (а иначе зачем ХП), то я бы задумался об основах.

← →
Dok (2006-08-03 15:59) [22]

> чтобы не кидать с клиента несколько запросов. а именно 4
> штуки

т.е. 4 запроса поменять значения у 2-х записей? 2 запроса. где четыре? И если это часто, то что-то в консерватории не так.

← →
StriderMan © (2006-08-03 15:59) [23]

> Очень странная задача

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

← →
StriderMan © (2006-08-03 16:04) [24]

> Dok (03.08.06 15:59) [22]

поле-то уникальное! поэтому приходится через промежуточное значение. итого 3. а 4 - SELECT чтобы определить что мы "наткнулись" на такую запись.

← →
Dok (2006-08-03 16:17) [25]

> ничего странного. Инкрементное или декрементное изменение
> уникального поля в таблице. когда натыкаемся на уже существующую
> запись, нужно поменять местами значения уникального поля
> в двух записях.

если это ПК, то играешся с огнем.

> поле-то уникальное! поэтому приходится через промежуточное
> значение. итого 3. а 4 - SELECT чтобы определить что мы
> "наткнулись" на такую запись.

Согласен 3 запроса. 4-й зачем?

← →
StriderMan © (2006-08-03 16:23) [26]

> если это ПК, то играешся с огнем.

что такое ПК? ключевое поле? нет не ключевое.

> 4-й зачем?

я ж написал зачем:

> а 4 - SELECT чтобы определить что мы "наткнулись" на такую запись.

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

← →
Dok (2006-08-03 16:34) [27]

> что такое ПК? ключевое поле? нет не ключевое.

Первичны Ключ

> от этого зависит логика.
> 1. узнаем, есть ли запись со значением поля, которое нам
> надо выставить в текущей записи.
> 2. Если нет - то просто меняем в текущей. Если есть - то
> меняем у найденной записи поле в некое свободное значение
> 3. меняем у текущей записи поле в нужное значение
> 4. меняем у записи, которую поменяли в пункте 2 значение
> поля в то, которое было у текущей до начала всей операции.
>

зачем это все?

← →
StriderMan © (2006-08-03 16:52) [28]

ну вот такая вот задача.

если конкретно,
то есть табличка. в ней есть уникальное поле "код". и есть кпопочки +/- которыми код можно менять.

← →
StriderMan © (2006-08-03 16:53) [29]

> зачем это все?

если знаете как это сделать проще, поделитесь, буду рад.

← →
Dok (2006-08-03 17:17) [30]

> то есть табличка. в ней есть уникальное поле "код". и есть
> кпопочки +/- которыми код можно менять.

т.е. на каждый пук пользователя лезем в базу?

← →
Johnmen © (2006-08-03 17:28) [31]

Точно что-то не то в консерватории...:)

← →
Ega23 © (2006-08-03 17:29) [32]

Если код может менять пользователь, то какое же это уникальное значение?

← →
StriderMan © (2006-08-03 17:30) [33]

> Dok (03.08.06 17:17) [30]
> Johnmen © (03.08.06 17:28) [31]

да, такая вот дурацкая система. Фичу не я придумал. в принципе на локальной базе работает быстро.

← →
StriderMan © (2006-08-03 17:31) [34]

> Ega23 © (03.08.06 17:29) [32]
> Если код может менять пользователь, то какое же это уникальное
> значение?

а почему бы и нет? уникальное в пределах таблицы. Если пользователь пытается ввести неуникальное, то корректно ругаемся.

← →
Ega23 © (2006-08-03 17:34) [35]

Я к тому, что ты его сам генерить должен.

← →
StriderMan © (2006-08-03 17:36) [36]

> Ega23 © (03.08.06 17:34) [35]
> Я к тому, что ты его сам генерить должен.

я его и генерю при добавлении записи. но пользователь в праве его менять.

← →
Ega23 © (2006-08-03 17:45) [37]

> я его и генерю при добавлении записи. но пользователь в
> праве его менять.

Непонятно. Честное слово, непонятно зачем такое поле нужно...

← →
StriderMan © (2006-08-03 18:41) [38]

> Ega23 © (03.08.06 17:45) [37]

это поле называет КОД. Это код элемента в справочнике. Некий уникальный идентификатор, ПОНЯТНЫЙ и доступный пользователю.

вы с 1С знакомы?

← →
Ega23 © (2006-08-03 18:48) [39]

> вы с 1С знакомы?

Нет.

> это поле называет КОД. Это код элемента в справочнике. Некий
> уникальный идентификатор, ПОНЯТНЫЙ и доступный пользователю.
>

Я такие поля сам генерю. И нехрен пользователю их менять.

← →
StriderMan © (2006-08-03 19:15) [40]

> И нехрен пользователю их менять

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

← →
Petr V. Abramov © (2006-08-03 19:34) [41]

> 1. узнаем, есть ли запись со значением поля, которое нам надо выставить в текущей записи.
А в это время висит транзакция, которая запись с таким значением только что вставила. Т.к. сия транзакция еще не завершена, узнаем, что записи нет.
2. Начинаем действовать исходя из этого. Пока действуем, нехорошая транзакция коммитится.
3. Сильно удивляемся.

Если кто подумает,что это "маловероятно" - законы Мерфи имеют приоритет над законами больших чисел. Electronically tested, как пишут на презрвативах.

← →
Dok (2006-08-03 19:34) [42]

← →
sniknik © (2006-08-03 19:48) [43]

> задачи товароучета сложно решать без возможности изменения идентификатора товара (кода, артикула, штрих-кода).
хм...
позвольте поинтересоваться, а вы с 1С знакомы?
если знакомы то должны знать, в 1С поле идентифицирующее запись, не только поменять, посмотреть нельзя... а то что вы видите, и меняете, оно вторично... (потому и можно)

← →
Petr V. Abramov © (2006-08-03 19:56) [44]

> Dok (03.08.06 19:34) [42]
> почему пользователь его вообще меняет?
потому что в общем случае он его вводит и может ошибиться. Системы кодировки могут быть достаточно хитрыми. К примеру, чаще всего выписываемый товар должен иметь короткий и простой код, типа 111, а другие - подлинне.

← →
paul_k © (2006-08-03 21:43) [45]

Уважаемые господа. просвятите пожалуйста что будет в результате исполнения следующего кода на MsSql сервере и как с этим боротся.
у паблика прав на селект из таблийц нету. есть только на выполнение процедур
есть процедура с кодом
...
declare @t_name varchar(30)
set @t_name = "authors"
exec ("select * from "+@t_name)
....
будет ли она работать под пабликом, у которого нет прав на выборку данных из таблицы authors?

← →
paul_k © (2006-08-03 21:50) [46]

а будет вот что
SELECT permission denied on object "authors", database "pubs", owner "dbo".

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

← →
Petr V. Abramov © (2006-08-03 22:13) [47]

> и как с этим правильно жить и работать?
я mssql не знаю, но что ты не в ту ветку вопрос задал - уверен :))))

← →
Anatoly Podgoretsky © (2006-08-03 22:33) [48]

paul_k © (03.08.06 21:50) [46]
Попробуй так
declare @t_name varchar(30)
declare @sql varchar(40)
set @t_name = "authors"
set @sql = "select * from "+@t_name
exec (@sql)

← →
Petr V. Abramov © (2006-08-03 23:49) [49]

> Anatoly Podgoretsky © (03.08.06 22:33) [48]
разница даже мне видна :)))

← →
paul_k © (2006-08-04 09:41) [50]

> [48] Anatoly Podgoretsky © (03.08.06 22:33)

Большое спасибо.Попробовал. и так попробовал и сяк попробовал и наперекосяк... :)))
А смысл перестановки, если в разруливании доступа дело?
предвиху вопрос задача мол идиотская, и нафиг тебе это не нужно
задача получить отчет о рыночной стоимости активов
есть тип актива (валюта, ЦБ, драгметалы, недвижимость)
соответственно есть "котировки" активов лежат в разных таблицах ибо это абсолютно разные сущности
соответсвенно можно писать кучу условий по разным типам активов. Что при добавлении нового типа активов ведет к переписыванию отчета.
А можно добавить настройку вида [тип актива], [имя таблицы котировок] [имя поля котировки]. И тогда придобавлении нового актива достаточно добавить запись в эту настройку и все.
Но у простого смертноко пользователя правов на запрос не может быть. Политики безопасности, мать их
И что делать? механихм динамического формирования запроса есть а как его применить то?

← →
Babay © (2006-08-04 10:51) [51]

ТО paul_k ©
В MS SQL есть такая штука как представление, пользователю даем права на селект из представления и делаем это в процедуре, а в представление пихаем что нужно и как нужно....
Если я все правильно понял это должно тебя спасти....

← →
ANB © (2006-08-04 12:03) [52]

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

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

Решение простое - для связок и ПК использовать искуственные ключи, которые генерятся автоматически и пользователь не может их менять (вопрос просмотра - дискуссионный), а внешние коды можно забивать в отдельные поля. И пусть пользователь делает с ними, что хочет. Главное, контролировать их с точки зрения бизнес-логики (например запрет дублей).

← →
StriderMan © (2006-08-04 12:07) [53]

> sniknik © (03.08.06 19:48) [43]
> > задачи товароучета сложно решать без возможности изменения
> идентификатора товара (кода, артикула, штрих-кода).
> хм...
> позвольте поинтересоваться, а вы с 1С знакомы?
> если знакомы то должны знать, в 1С поле идентифицирующее
> запись, не только поменять, посмотреть нельзя... а то что
> вы видите, и меняете, оно вторично... (потому и можно)

Так я и говорю об этом. Разумеется в таблицах есть поле ID которое пользователю недоступно, также как в 1С. Но я говорю о поле код, которое в том же 1С уникально, и доступно пользователю.

← →
paul_k © (2006-08-04 12:32) [54]

> [51] Babay © (04.08.06 10:51)

низя.... Безопасность так построена.

← →
jiny (2006-08-04 14:01) [55]

У меня это все прекрасно работает, пользователей приучил что ID - это уникальный идентификатор, который генерит сервер, и который ни в коем разе нельзя поменять никому, даже мне, также есть поле ID_doc, где также генериться сервером какой-нить номер накладной и которое пользователь может поменять(причем id сделки фиксируется мелким шрифтом на наряде на укомплектацию и на самой накладной, и никому это не мешает), причем чтобы не было путанницы, пользователи всегда ориентируются по номеру сделки (ID), даже если номер накл.изменен

StriderMan © (04.08.06 12:07) [53]
Так я и говорю об этом. Разумеется в таблицах есть поле ID которое пользователю недоступно, также как в 1С. Но я говорю о поле код, которое в том же 1С уникально, и доступно пользователю.
так если поле код уникальное, что прописано на сервере, в чем проблема что туда будет вводить пользователь? сервер в любом случае дубль не пропустит. и зачем тут предварительные селекты?
а связь по этому коду совсем не нужна, только по внутреннему скрытому от пользователя ид.

Читаю-читаю, и все больше мне задача кажется странной. Кому нафиг нужны коды, которые меняются местами?!!! Сегодня карандаш 13-й, линейка 15-я. Завтра наоборот. Зачем? Или таки я не понял смысла сего.

> stud © (04.08.06 15:34) [56]
> так если поле код уникальное, что прописано на сервере,
> в чем проблема что туда будет вводить пользователь? сервер
> в любом случае дубль не пропустит. и зачем тут предварительные
> селекты?
> а связь по этому коду совсем не нужна, только по внутреннему
> скрытому от пользователя ид.

Связей по нему и нет. А конкретная проблема при изменении кода описана тут [26], [28].

> Sergey13 © (04.08.06 15:41) [57]
> Читаю-читаю, и все больше мне задача кажется странной. Кому
> нафиг нужны коды, которые меняются местами?!!! Сегодня карандаш
> 13-й, линейка 15-я. Завтра наоборот. Зачем?

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

> Связей по нему и нет. А конкретная проблема при изменении
> кода описана тут [26], [28].

И таких табличек, где это нужно делать - не одна, как я понял. Тогда только динамический SQL. Можешь больше тут не спорить.

Sergey13 © (04.08.06 15:41) [57]
Кому нафиг нужны коды, которые меняются местами?
ну иногда нужны только они обычно не цифровые и что-то вроде карандаш красный - каркрас например, подобная вещь у меня в справочнике мед услуг, каждая услуга имела свой код тогда достаточно быстро человек ее находит.

StriderMan © (04.08.06 15:44) [58]
Связей по нему и нет. А конкретная проблема при изменении кода описана тут [26], [28].
вот в [26] второй пункт смущает совершенно. т.е. юзер видит ЧТО НА ЧТО он меняет, но если такой уже есть, то никто не знает на какой он изменится (в некоторое свободное значение)???
это что-то из области "угадай мелодию" получается. по идее нельзя изменить существующий код на тот, который уже есть в системе. а если очень хочется - то пускай сначала изменят тот который есть руками.

ANB © (04.08.06 15:58) [60]
И таких табличек, где это нужно делать - не одна, как я понял.
и связей нет..... т.е. структура на справочники не завязана....

> [61] stud © (04.08.06 15:59)

Я говорил не про коды вообще, а про меняющиеся местами коды.
У автора это уже не код, а поле для сортировки получается. А если так - пусть меняет. Мне не жалко. 8-)

Sergey13 © (04.08.06 16:07) [63]
У автора это уже не код, а поле для сортировки получается
да уж)) достаточно бредовая идея, особенно для многопользовательской системы. вот начнет каждый под себя менять)))))
и будут они весь день только этим и заниматься)))

> да уж)) достаточно бредовая идея, особенно для многопользовательской
> системы. вот начнет каждый под себя менять)))))

администрирование предполагается централизованное.

> ANB © (04.08.06 15:58) [60]
> Можешь больше тут не спорить.

А я и не спорю. Подходящий мне вариант [6].

> stud © (04.08.06 15:59) [61]
> вот в [26] второй пункт смущает совершенно. т.е. юзер видит
> ЧТО НА ЧТО он меняет, но если такой уже есть, то никто не
> знает на какой он изменится (в некоторое свободное значение)?
> ??

Читайте внимаетльно и до конца.

для тех кто в танке или просто не понял что нужно:
датасет:
ID/код/ Имя 111 1 Запись1 >222 2 Запись2 //текущая запись

Пользователь жмет кнопочку (-)
Получаем:

ID/код/ Имя > 222 1 Запись2 //текущая запись 111 2 Запись1

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

> то достаточно в процедуре реализовать изменение нужных полей
> во всех таблицах сразу

сразу во всех не надо! нужно в конкретной таблице провернуть такую операцию [65]. По полю КОД нет никакой связи в таблицах! в других менять не надо. фишка в том что оно уникальное!
Наиболее близкая задача - это поменять местами два элемента в массиве. такую задачу решают обычно через третью переменную. вот также и тут. коды можно поменять только через некое третье значение.

Короче от темы уже совсем отошли.

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

> stud © (04.08.06 17:43) [68]

да. именно так.
сейчас работает через DataSet.Edit... Что по сути и есть несколько запросов (использую IBQuery-UpdateObject). Попробую через Execute Stateмent, сравню что быстрее.

> что за блоки?

declare
begin
-- много операторов PL/SQL
end;

> StriderMan © (04.08.06 18:02) [73]

Кстати, раз уж пишешь под FB - есть ли в нем аналог NVL или IsNull, чтобы без геморроя нулловые поля сравнивать ?

> там несколько запросов. а хотелось одним, чтоб быстрее. а одним - только ХП.
только это для MSSQL (!!!) не знаю сработает а файребирде, или нет.

тест
UPDATE Unik SET No = (SELECT No FROM Unik n WHERE n.ID<>Unik.ID AND (N.ID=1 OR N.ID=2)) WHERE ID=1 OR ID=2
приCREATE TABLE Unik (ID INT Identity(1, 1) PRIMARY KEY, No INT, Name VarChar(30)) CREATE UNIQUE INDEX No ON Unik (No)

думаю ясно чем заменяются 1 и 2 в реальном запросе. ;)

> sniknik © (04.08.06 18:08) [76]
UPDATE Unik SET No = (SELECT No FROM Unik n WHERE n.ID<>Unik.ID AND (N.ID=1 OR N.ID=2)) WHERE ID=1 OR ID=2

че-то сомнительно что это прокатит. но попробую. на след. неделе. уже пора закругляться :)

Имя таблицы как параметр запроса Найти похожие ветки