ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Каскадный ФК
25 сообщений из 55, страница 2 из 3
  2  все
Каскадный ФК
    #39195831
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Симонов Денис> ну про каскады вообще страшилок много

На заборах тоже пишут, не читай на ночь. :)

Симонов Денис> Во первых порядок их срабатывания вовсе
Симонов Денис> не тот что многие ожидают

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

Симонов Денис> Во вторых цепочка каскадов это всё равно что цепочка триггеров

Тогда уж говорите, что и триггеры тоже зло.
А заодно предложите альтернативу удалению
не каскадами и не триггерами. Впрочем, я
заранее знаю, что вы скажете.

Симонов Денис> А уж если на каждой таблице участвующей
Симонов Денис> в каскаде ещё и триггеры на удаление навешаны

Во-первых, это несерьёзно, во-вторых, ничего
страшного при этом не будет, не "пропало".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
18.03.2016, 22:05
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39195886
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
Гаджимурадов РустамПроблема ещё актуальна или уже разобрался?



видимо тут передмудрил

Код: plsql
1.
2.
ALTER TABLE TABLEZ ADD CONSTRAINT FK_TABLEZ_3 FOREIGN KEY (FIELD1_ID, FIELD2_ID, FIELD3_ID, FIELD4_ID, FLAG, FAKE) REFERENCES TABLE1 (C, FIELD2_ID, FIELD3_ID, FIELD4_ID, FLAG, FAKE) ON UPDATE CASCADE;
ALTER TABLE TABLEZ ADD CONSTRAINT FK_TABLEZ_6 FOREIGN KEY (FIELD5_ID, FIELD1_ID, FIELD3_ID, FIELD4_ID) REFERENCES TABLE1 (C, FIELD1_ID, FIELD3_ID, FIELD4_ID) ON UPDATE CASCADE;



несколько одинаковых полей были в разных ФК
...
Рейтинг: 0 / 0
19.03.2016, 02:19
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196223
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
Гаджимурадов Рустам,

вот только почему если в разных ФК используется одно и то же поле каскад не проходит?
вот сейчас смотрю на тело договора. там один фк на шапку. в нем есть поле признака. и второй фк на тело другого документа. там тоже используется это же поле. каскад споткнулся
...
Рейтинг: 0 / 0
19.03.2016, 22:03
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196397
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Swv> вот только почему если в разных ФК используется
Swv> одно и то же поле каскад не проходит?

Я не очень понял вопрос. Участие одного поля
в несколько внешних ключах не запрещено и
работает (возможно с багами). Ссылки из некольких
полей на одно поле (т.е. много деталей у мастера)
тем более не запрещено, работает годами.

Так что лучше приводи DDL. И без всяких новоязов
типа "каскад споткнулся", а точное сообщение об
ошибке и DML, который к нему привёл.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
20.03.2016, 13:10
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196445
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
Гаджимурадов Рустам,


вот я тоже думаю, что не запрещено. но поубирав некоторые ФК на этих таблицах спотыкаться перестал
DDL слишком большой будет )

а сообщение страндартное
violation of FOREIGN KEY constraint "".
violation of FOREIGN KEY constraint "FK_BODY_1" on table "BODY".
Foreign key reference target does not exist.
Problematic key value is ("PART_ID" = 77, "MAIN_ID" = 80, "HEADER_ID" = 302, "YEAR_ID" = 3, "ORG_ID" = -1).
At trigger 'CHECK_292'
At trigger 'CHECK_290'
At trigger 'CHECK_235'.
...
Рейтинг: 0 / 0
20.03.2016, 15:09
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196448
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
body это не обновляемая в данном случае таблица. до нее каскад дошел. и споткнулся
...
Рейтинг: 0 / 0
20.03.2016, 15:11
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196452
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
SwvDDL слишком большой будет

DDL двух таблиц master + detail не может быть очень большим, если ты конечно не 255 столбцов в каждой создал.
...
Рейтинг: 0 / 0
20.03.2016, 15:19
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196456
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
сейчас нашел в одной из таблиц , которые по идее должны обновиться, не каскадный ФК. поставил у него CASCADE
и споткнулось уже на этой таблице
...
Рейтинг: 0 / 0
20.03.2016, 15:27
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196457
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
Симонов Денис,

от обновляемой таблицы по набору полей зависит другая, а от нее другая... и тд. всего штук 15-20. вот по ним и идет каскад. так что думаю смысла нет смотреть на две таблицы
...
Рейтинг: 0 / 0
20.03.2016, 15:29
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196461
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Swv> DDL neeoei? aieuoie aoaa? )

Как верно заметил Денис, DDL двух (или трёх)
задействованных таблиц большим быть не может.
Даже если много полей - можешь просто выкинуть
ненужные, оставив только поля PK и FK.

И DML, который приводит к ошибке, не забудь привести.
Не будет DDL+DML - вряд ли кто-то сможет помочь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
20.03.2016, 15:37
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196467
Ну смотри
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ну смотри
Гость
Swv, столько гемора из-за Swv...чтобы таблицу пятых документов можно было бы быстро отфильтровать по этому признаку не joinив все вплоть до первой таблицы.

Ну смотри. Ты фильтруешь по полю, которое у тебя продублировано в табличке нижнего уровня. Для эффективной фильтрации у тебя должен быть подходящий индекс. Иначе, если табличка большая - может получиться грустно.
...
А теперь - "с джойном". Ты фильтруешь по полю в табличке верхнего уровня. Эта табличка наверняка меньше, чем табличка "нижнего уровня". Фильтруется быстро, стало быть. А потом к остатку джойнятся только те записи, которые ты должен увидеть. Выигрыш по скорости - налицо.

Даже из-за этого есть смысл все переделать на искусственные ключи на основе целочисленной последовательности.
Выигрыш - колоссальный: не нужно каскадно обновлять данные, уменьшается размер базы, упрощается сопровождение, во мнгих случаях возрастает скорость обработки.
...
Рейтинг: 0 / 0
20.03.2016, 15:47
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196470
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
Ну смотри,

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


DDL порезал.

 
DDL

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
 CREATE TABLE body_table (
    C                                INTEGER NOT NULL,
    HEADER_ID                        INTEGER NOT NULL,
    YEAR_ID                          INTEGER NOT NULL,
    ORG_ID                           INTEGER NOT NULL,
    FLAG                             FLAGDOM NOT NULL,
    FAKE                             SMALLINT DEFAULT 0 NOT NULL,
    DELETED                          DOM_DELETED
);


CREATE TABLE SPECS (
    C                     INTEGER NOT NULL,
    YEAR_ID               INTEGER NOT NULL,
    body_table_ID         INTEGER NOT NULL,
    ORG_ID                INTEGER NOT NULL,
    FLAG                  FLAGDOM NOT NULL,
    FAKE                  SMALLINT NOT NULL,
    DELETED               DOM_DELETED
);


CREATE TABLE STARTP2 (
    C                     INTEGER NOT NULL,
    YEAR_ID               INTEGER NOT NULL,
    SPECS_ID              INTEGER NOT NULL,
    ORG_ID                INTEGER NOT NULL,
    FLAG                  FLAGDOM NOT NULL,
    FAKE                  SMALLINT NOT NULL,
    body_table_ID         INTEGER NOT NULL,
    DELETED               DOM_DELETED
);




/******************************************************************************/
/***                           Unique constraints                           ***/
/******************************************************************************/

ALTER TABLE body_table ADD CONSTRAINT UNQ1_body_table UNIQUE (C);
ALTER TABLE SPECS ADD CONSTRAINT UNQ1_SPECS UNIQUE (YEAR_ID, body_table_ID, ORG_ID);
ALTER TABLE STARTP2 ADD CONSTRAINT UNQ2_STARTP2 UNIQUE (C, SPECS_ID);


/******************************************************************************/
/***                              Primary keys                              ***/
/******************************************************************************/

ALTER TABLE body_table ADD CONSTRAINT PK_body_table PRIMARY KEY (C, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE);
ALTER TABLE SPECS ADD CONSTRAINT PK_SPECS PRIMARY KEY (C, body_table_ID, YEAR_ID, ORG_ID, FAKE, FLAG);
ALTER TABLE STARTP2 ADD CONSTRAINT PK_STARTP2 PRIMARY KEY (C, body_table_ID, HEADER_ID, YEAR_ID, ORG_ID, FLAG);


/******************************************************************************/
/***                              Foreign keys                              ***/
/******************************************************************************/

ALTER TABLE SPECS ADD CONSTRAINT FK_SPECS_2 FOREIGN KEY (body_table_ID, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) REFERENCES body_table (C, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) ON UPDATE CASCADE;
ALTER TABLE STARTP2 ADD CONSTRAINT FK_STARTP2_3 FOREIGN KEY (body_table_ID, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) REFERENCES body_table (C, HEADER_ID, YEAR_ID, ORG_ID, FLAG, FAKE) ON UPDATE CASCADE;
ALTER TABLE STARTP2 ADD CONSTRAINT FK_STARTP2_5 FOREIGN KEY (SPECS_ID, body_table_ID, YEAR_ID, ORG_ID, FAKE, FLAG) REFERENCES SPECS (C, body_table_ID, YEAR_ID, ORG_ID, FAKE, FLAG) ON UPDATE CASCADE;




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

обновляю так

Код: plsql
1.
2.
3.
update body_table
set HEADER_ID = 30071,year_id = 3
where c=  80
...
Рейтинг: 0 / 0
20.03.2016, 15:54
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196486
Ну смотри
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ну смотри
Гость
Swv...но дублировал еще по той причине, что было необходимо, чтобы в тело второго документа нельзя было добавить ничего, кроме как из тела первого документа, тк первый есть основание для второго...
...

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

Насчет суррогатных кл.чей смотри сюда: http://www.informix.com.ua/articles/key/key.htm
...
Рейтинг: 0 / 0
20.03.2016, 16:14
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196540
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
Ну смотри,

ок. есть вот такие вот таблицы
 

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
CREATE TABLE Z1 (
    C     INTEGER NOT NULL,
    NAME  CHAR(10)
);


CREATE TABLE Z1_1 (
    C      INTEGER NOT NULL,
    Z1_ID  INTEGER NOT NULL,
    NAME   CHAR(10)
);


CREATE TABLE Z2 (
    C        INTEGER NOT NULL,
    NAME     CHAR(10),
    BASE_ID  INTEGER NOT NULL
);


CREATE TABLE Z2_1 (
    C        INTEGER NOT NULL,
    Z2_ID    INTEGER NOT NULL,
    Z1_1_ID  INTEGER NOT NULL,
    NAME     CHAR(10)
);




/******************************************************************************/
/***                              Primary keys                              ***/
/******************************************************************************/

ALTER TABLE Z1 ADD CONSTRAINT PK_Z1 PRIMARY KEY (C);
ALTER TABLE Z1_1 ADD CONSTRAINT PK_Z1_1 PRIMARY KEY (C);
ALTER TABLE Z2 ADD CONSTRAINT PK_Z2 PRIMARY KEY (C);
ALTER TABLE Z2_1 ADD CONSTRAINT PK_Z2_1 PRIMARY KEY (C);


/******************************************************************************/
/***                              Foreign keys                              ***/
/******************************************************************************/

ALTER TABLE Z1_1 ADD CONSTRAINT FK_Z1_1_1 FOREIGN KEY (Z1_ID) REFERENCES Z1 (C);
ALTER TABLE Z2 ADD CONSTRAINT FK_Z2_1 FOREIGN KEY (BASE_ID) REFERENCES Z1 (C);
ALTER TABLE Z2_1 ADD CONSTRAINT FK_Z2_1_1 FOREIGN KEY (Z2_ID) REFERENCES Z2 (C);




z1 и z2 это два документа.
Z2.BASE_ID это базовый документ Z1. Соответственно в Z2_1 для конкретного документа не должно быть ничего, чего нет в Z1_1 соответствующего документа Z2.BASE_ID

Какое ограничение добавить? По мне так в Z2_1 надо добавить тоже base_id и создать ФК Z2_1 (Z2_id,BASE_ID) REFERENCES Z2 (C,BASE_ID). тогда добавление как должно быть не пройдет
...
Рейтинг: 0 / 0
20.03.2016, 18:15
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196554
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
могу только погрешить на зацикленные каскадные ссылочные действия ) как говорил kdv.

Есть какой нибудь запрос на выявления этих циклов?
...
Рейтинг: 0 / 0
20.03.2016, 18:51
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196555
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
SwvЕсть какой нибудь запрос на выявления этих циклов?
я думал, что он у меня тут
www.ibase.ru/sysqry/

но оказывается, что нет. по идее, можно выполнить запрос 9, и просканировать его на "зацикливание".
...
Рейтинг: 0 / 0
20.03.2016, 19:12
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196580
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
по стеку ошибки удалось однако узнать порядок срабатывания системных триггеров этих самых каскадов.

получилась такая картина

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
HEADER1 FOREIGN KEY (HEADER0_BODY_ID, HEADER0_ID, YEAR_ID, ORG_ID, FLAG, FAKE) REFERENCES 
HEADER0_BODY (C, HEADER0_ID, YEAR_ID, ORG_ID, FLAG, FAKE) ON UPDATE CASCADE;

	HEADER1_BODY FOREIGN KEY (HEADER1_ID, HEADER0_BODY_ID, YEAR_ID, ORG_ID, FAKE, FLAG) REFERENCES 
	HEADER1 (C, HEADER0_BODY_ID, YEAR_ID, ORG_ID, FAKE, FLAG) ON UPDATE CASCADE;

		HEADER2_BODY FOREIGN KEY (HEADER1_BODY_ID, HEADER1_ID, HEADER0_BODY_ID, YEAR_ID, ORG_ID, DELETED) REFERENCES 
		HEADER1_BODY (C, HEADER1_ID, HEADER0_BODY_ID, YEAR_ID, ORG_ID, DELETED) ON UPDATE CASCADE;



обновлялась HEADER0_BODY. а споткнулась на HEADER1_BODY
...
Рейтинг: 0 / 0
20.03.2016, 20:35
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196593
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
выполняется каскад так

HEADER0_BODY
HEADER1
HEADER2
HEADER1_BODY
HEADER2_BODY
но получается, что сначала обрабатывается HEADER1_BODY, а потом уже HEADER2. И доходит до HEADER2_BODY и обламывается.

что намудрил?

HEADER2 имеет ссылку на документ-основание HEADER1. а чтобы "залочить" HEADER2_BODY на соответствующий HEADER1_BODY в HEADER2_BODY имеется ссылка и ФК на HEADER1_BODY.
Вот тут видимо и перемудрил.
вот только как поправить с учетом того, что у второго документа есть документ документ-основание и в теле второго документа не должно быть ничего кроме как из тела документа-основания
...
Рейтинг: 0 / 0
20.03.2016, 21:29
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196613
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
SwvСоответственно в Z2_1 для конкретного документа не должно быть ничего, чего нет в Z1_1 соответствующего документа Z2.BASE_IDЯННП. А то, что понял - не уверен, что понял правильно.
Более того, у тебя и с именованием объектов проблемы.

Затрудняешься объяснить - приводи таблички с данными.
Если Z11 и Z21 - это две таблицы для одной сущности
(т.е. для разных её атрибутов) - так и скажи.
...
Рейтинг: 0 / 0
20.03.2016, 22:18
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196643
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Swv
Участник
Гаджимурадов Рустам,

z1, z1_1 - шапка-тело ) z2 ,z2_1 аналогично
...
Рейтинг: 0 / 0
20.03.2016, 23:10
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196647
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
И? Какое отношение Z21 имеет к Z11 или Z1 ?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
20.03.2016, 23:18
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196692
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
чччД
Участник
Имхо, автору следует обратиться в http://www.sql.ru/forum/db-design
...
Рейтинг: 0 / 0
21.03.2016, 02:03
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196747
tip78
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tip78
Участник
МимопроходящийSwv, советовать тебе сейчас что-либо, не зная предметной области и поставленной задачи смысла не имеет.
есть общие принципы проектирования БД (помимо нормализации).
один из них - избегать составных ПЕРВИЧНЫХ ключей.
нужна уникальность по группе полей - создавай УНИКАЛЬНЫЙ ключ (но не первичный).
а первичный ключ обычно делают суррогатным, на генераторах, сиквенсах, автоинкрементах, UUID-ах и т.п.
на такой ключ гораздо удобнее ссылаться из FK и не нужно городить каскадные обновления.

к слову, легенда гласит, что если на ПК вообще забить, mysql его сам создаст произвольно
...
Рейтинг: 0 / 0
21.03.2016, 09:12
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196781
WildSery
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
WildSery
Участник
kdvэто не анекдот.Каждый анекдот - это зачастую реальное событие, гиперболизированное вплоть до абсурда, так что не вижу никаких противоречий.

Гаджимурадов РустамКак будто если бы удаление в этой БД было на
триггерах, а не каскадное - стало бы легче/лучше.Речь не о способе реализации, а о самой архитектуре.
...
Рейтинг: 0 / 0
21.03.2016, 09:57
| Ответить | Цитировать | Написать  
Каскадный ФК
    #39196930
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
WildSery> Речь не о способе реализации, а о самой архитектуре.

Это лишь игра слов, не более. Если бы "архитектура" в этой
БД была на триггерах, а не на каскадах - лучше бы не было.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
21.03.2016, 11:50
| Ответить | Цитировать | Написать  
25 сообщений из 55, страница 2 из 3
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Каскадный ФК
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=39196445&tid=1562244]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 35ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 65ms
get tp. blocked users:
 1ms
others: 15ms
total:  163ms
созд. / загр.: 163ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]