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

← →
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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет.

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

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

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

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

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