|
|
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 13:19 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Видел, сам работаю (около 300 пользователей). Насколько эффективен - если логика вся на сервере, то эффективен. Из подводных камней - тупость аксесав некоторых моментах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 15:21 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Тупость только в некоторых моментах, просто не до конца написал. Дело в том, что аксес при конекте выгребает кучу нужной ему информации о таблицых, вьюхах и ещё много чего. Ещё периодически валится на выборке большого количества данных в форму. Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 15:26 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Если проэкт большой не только по числу юзеров но и по функционалу , то на Access начнеш быстро, но потом дорабатывать и сопровождать запаришся. Но это не беда. У нас например клиент полиморфный - часть на AccessMDB, часть на AccessADP часть на VB часть на C# ASP Каждый по своему хорош Если есть возможность выбора , то этетически мне ближе C# AccessADP неплох если нужен быстрый старт с резким набором функционала (этакий рабочий(и работающий) протатип ), но затем нужен переход на платформу с нормальной поддержкой ООП иначе в конце будет каша неудобоваримая. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 15:58 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
ну тогда самый оптимальный вариант ассембер - всё будет в тыоих руках.... главное что нужно получить от проги если ввод - акса + SQL за глаза, а ежели какихто общетов - в SQL можно присабачить расширенные процедуры хоть на чем и вперед. тоже самое можно сделать и для клиентской части. а связь аксом-SQL отличный вариат для выборки данных для клиента. на аксе можно писать великолептных клиентов. главное правильно распределить ввыплняемые задачи. Хранимая работает быстро на серваке - а аксес не принимает данные. Если с условиями ту же хранимую, то всё нормально. на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается. тут был вопрос по поиску данных в отчете в 200 страниц!!! грамотнее было-бы формировать отчет в одну страницу, но с нужными данными распечатать(подготовить на печать) 200 страниц - а потом их анализировать? а комп зачем? - пишмашка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 19:55 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся - см. посты Hummer за минусом постов вадя ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.10.2003, 21:01 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Из подводных камней - тупость аксесав некоторых моментах хотелось бы знать кто и что считает тупостью акса. ваши мниния , господа! моё - нужно городить выделение строки цветом.(хотя и решается просто) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2003, 17:51 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Я бы не стал категорично применять слово тупость . Выражаюсь более мягко - негибкость . Вот обьеденить бы 3 продукта: Paradox (Corel, borland, может еще куому-то сплавят), Sybase Power Builder и Access! У каждого из них есть такие изюминки, которые влюбляют раз и надолго. надо только просечь. Так вот - жесткая привязка проекта adp к конкретному SQL серверу - это похороны сверхперспективного продукта. Если разработчики не одумаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.10.2003, 18:23 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2 Pavel Масштабируемость это дело SQL сервера. Но коммерческий проект я бы на adp разрабатывать не взялся Все таки можно поподробнее - почему? Я как раз взялся за разработку почти с нуля достаточно крупного проекта, причем часть его уже крутится у клиента на 1С. Переписывать будем все. Неужели это более тормозной и неправильный путь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 10:03 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Мля... Псиал-писал, в итоге прервалось соединение. Писать устал - поэтому выборка основных тезисов: 1) Все зависит от сервера и только от сервера. 2) Руки кривые - на Микрософт не пеняй. 3) 200 страниц отчета и поиск нужной - в морг 4) "Разруха прежде всего в головах..." (с) Булгаков ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 14:56 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2Тёмный ну ты просто гений.... 2Odess пиши на том что, знаешь и то что нравится. лично мне нравиться очень система команд PDP11(кто помнит, тот знает) и ассемблер к ней.... я бы сделал проект на ADP+SQL2000. - API подключать можно (без особых проблем). расширенные процедуры (на клиенте и на сервере(повторяюсь)) хоть на чем. вариант RUNTIME (ADE) почти exe. полный комплект мелкосовтовких примочек(типа офиса) - это по происхождению. описалово есть приличное. самое главное чтоб голова была. и если писать командой - так чтоб народ был умеющий работать в команде.(а это большая редкость. из практики) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 16:38 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Писал довольно давно проект на ADP. Действительно, очень быстро растет функционал на Accesse. Со временем, когда размер ADP файла после сжатия стал более 10M, и я запарился с падениями Access, стал выносить оттуда классы в VB, и делать COM-библиотеки - разгрузил более 60% кода, да и работать все стало в 2 раза быстрее. Часть критичных к быстродействию классов потом была еще переписана на С++, и получил весьма адекватное по быстродействию приложение. Далее. Действительно, грид на Access не позволяет по-человечески изворачиваться с раскраской, колонками-картинками, выпадающими календариками ипрочими прелестями. Но это не страшно, т.к. такое требуется дай бог в 15% всех гридов в приложении. Поэтому постепенно, уже в процессе отладки некоторые формы со вложенным гридом были переписанны с использованием Infragistics UltraGrid (очень похож внешне на Access-овский, поэтому вписывается весьма органично). Это, плюс повсеместное использование иерархических справочников и собственного ActiveX элемента-дерева, который понимает 3 вида организации иерархии без единой строчки кода, плюс ресайз практически всех форм, дало приложению вполне профессиональный вид и функционал. (а отчеты делать в Access - вообще песня!) Так что, большие и серьезные проекты на Access делать можно и нужно, особенно в условиях нехватки разработчиков. Для сравнения на аналогичный проект полностью на С# потребуется в 3 раза больше народу, это - по-минимуму. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2003, 22:56 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Odess Все таки можно поподробнее - почему? Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 06:44 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
вадя писал:на фига гнать на клиента столько данных? что оператор сможет визуально их обработать? нада правильно сформировать данные хранимкой и их отогнать на клиента - в этом мастерство и заключается. Это отчёт с различными показателями всего за МЕСЯЦ. Просто количество обрабатываемых в ДЕНЬ записей очень велико - порядка 1,5 млн. записей. Разумеется, все записи не требуются - цифра приведена для того, чтобы было понятно, каков объём данных. Данные группируются по определённым критериям и выводятся не в отчёт, а на форму. Мастера есть, не сумлевайтесь:) 2 Pavel Ну с тупостью погорячился, просто некоторые моменты в поведении аксеса крайне поражают:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 09:19 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2Hummer >просто некоторые моменты в поведении аксеса крайне поражают:) Спорю на банан - нет такой системы в которой что-нибудь да как-нибудь не поразило разработчика (правда, Акес иногда поражает на смерть ) == Через терни - к зведам :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 09:24 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2 Pavel Да хотя бы потому, что adp требует Public на сервере. А это серьезная угроза безопасности. Что требует ? Поясни для бестолкового ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 10:16 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 11:41 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Интересно насколько масштабируемо решение Сиквел+ADP.Видел ли кто нибудь крупный рабочий комплекс (80-150 интенсивно работающих пользователей и размер базы от 50 гигабайт). Вопрос о том,насколько эфективен будет клиент по сравнению с другими (ODBC и пр.) Какие подводные камни при такой реализации. Есть рабочий проект. Есть работа с одним сервером БД другого офиса по выделеному каналу. Пользователей порядка 100. База до 10 Гб (пока ). Все работает. Не скажу летает, но серьезных сбоев и задержек не наблюдается. По сравнению с ODBC - однозначно лучше...имхо. Другие варианты не пробовал, пока и этот устраивает. Возможно и нужно будет переходить на другие платформы, но при грамотном написании серверной и клиентской части запас масштабируемости довольно большой. P.S. Совсем недавний пример грамотного написания: была форма сбора статистической информации, переписал по-другому хранимую процедуру, и немного форму, время работы изменилось с 10-20 сек до 1-3 сек. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 11:55 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2 Pavel Public - это стандартная роль MSSQL. Позволяет много такого, что позволять не надо бы. В небольшом и некоммерческом проекте на это можно забить. А вот для коммерческого проекта это никуда не годится. Бедный MSSQL. И ничего-то коммерческого на нем не напишешь, так поиграться только :) Напиши это в конфу по MSSQL :) А в аксессе есть стандартная группа Users, куда тоже попадают все пользователи базы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.10.2003, 14:47 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Могу сказать про свое негативное впечатление об ADP/ADE. Многое касается только крупных проектов. 1. То что ADE часто валится без всяких на то причин и имеет неприличный размер, к этому думаю все привыкли. Под валится, имею в виду не создается ADE 2. Объекты внутри часто, просто херятся, даже эспортнуть нельзя, без опять-таки видимых причин. 3. Компилятор может не замечать ошибок, ну это ладно, мелочи жизни. 4. Очень хреново работать с ActiveX-контролами. Блин, даже свойства не отображаются нормально. Список свойств и методов недоступен при нажатии на точку. Приходится что-то делать сначала на VB6, а потом переносить код в Access, а потом иногда еще и править из-за некоторой несовместимости. 5. Некоторые ActiveX-контролами в Access глючат, некоторые выдают ошибки, такие, что работать с ними просто невозможно. 6. Из-за привычки ADE самохериться приходится создавать головной ADE, который имеет ссылки на остальные, запускать это можно только 1 раз (типа не dll:-), если меняется что-то в подчиненных ADE приходится пересоздавать головные. Геморрой еще тот. 7. Очень неприятная особенность при большой БД. Access скачивает себе список всех объектов БД при подключении: вьюх, таблиц, хр. процедур, функций. При большом количестве объектов на сервере такие чудные мгновения могут сильно растянуться. Если ADE имеет ссылки на другие ADE, то они при обращении к ним радостно сделают то же самое. 8. С API дружит хреново, почему у контролов нет хендлеров до сих пор непонятно. Функционал втроеных контролов оставляет желать много лучшего. 9. Ну и куча глюков о которых вспоминать нет времени, да и памяти никакой не хватит. З.Ы. Ну, а плюсы сами знаете :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 14:14 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде. 1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру? И "не создается ADE" - это как? Может просто беда с проектом вышла? 2. Опять таки беда с проектом? Декомпайл/восстановить/сжать никак не помогает? 3. Опять беда с проектом? Что ж это за размер такой, что он так по черному глючит? 4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается. 5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает... 6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись. 7. Ну есть такое, есть... 8. Хендлеров нет - потому что аксесовский контрол (не в фокусе) ни фига и не окно. Откуда ж там хендлеру взяться? Экселевские ячейки тоже без хендлеров, но это вроде как и не мешает. 9. См. п.7 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 14:34 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
2Лох Позорный полностью подписываюсь под тем что ты ответил. полностью подписываюсь под тем что ты ответил. полностью подписываюсь под тем что ты ответил. полностью подписываюсь под тем что ты ответил. !!!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 16:17 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
автор писал:И все это (за искл. п.7) - кажись особенности аксеса вообще, а не именно адп/аде Однако утешает это мало :-) автор писал:1. Неприличный размер - это сколько? Особенно в сравнении с такой же функциональностью, реализованной на VB к примеру? И "не создается ADE" - это как? Может просто беда с проектом вышла? Да по разному бывает. Бывает и создается, а некоторые формы отказываются работать. Размер может быть метров под 20. Глюки накапливаются каким-то образом, сравнивать с VB, думаю, не коректно, хотябы потому, что VB создает exe-ик каждый раз заново. А решение проблем - восстановление из BackUp :-) автор писал:4. Через ссылки не пробовал нужные библиотеки подключать? И явно тип описывать? У меня так еще в 97-м (мдб разумеется) все доступно и через точку все что нужно вываливается. Когда на форму кидаешь ActiveX, он и так в референсах прописывается. Если его объявить, например, как Код: plaintext автор писал:5. Есть такое. Так ведь контролы глючат, а не аксес. Хотя... кто ж его знает... В VB-то пашут, значит Access глючит. автор писал:6. Если меняется что-то в библиотечных ade - ни фига не надо пересоздавать головной. Разумеется если интерфейсы не изменялись. Надо, хоть букву одну измени и вперед, пересоздавать головной ADE! автор писал:8. Хендлеров нет - потому что аксесовский контрол (не в фокусе) ни фига и не окно. Откуда ж там хендлеру взяться? Экселевские ячейки тоже без хендлеров, но это вроде как и не мешает. Кто значит не окно? В какой не в фокусе? В виднах все, что есть окна. Я даже их хендлеры могу узнать (естественно не от Access'а). Только использовать это не получается. А в принципе на некрупных проектах и не крупных базах, ADE очень неплох. Про MDB можно спокойно забыть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 18:06 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Да, чего собственно зашел-то :-) Хотел узнать можно ли программно создать ADE? Если нет, вот вам еще один минус :-) В 97-м была недокументированная функция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 18:16 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Хотел узнать можно ли программно создать ADE в своё время была задачка написать прогу , которая распечатывала бы свой исходник. а на фига? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 19:12 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
автор писал:Хотел узнать можно ли программно создать ADE в своё время была задачка написать прогу , которая распечатывала бы свой исходник. а на фига? Представь. Есть головной ADE, у него ссылки на 10-20 других ADE, и все эти ADE имеет сслыку на один общий ADE, где находятся общие формы и модули. А теперь мы возмем и добавим пару строчек в этот общий, что нам потом надо будет сделать? Правильно, пересоздать все ADE. Поверь это не самое веселое занятие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 20:08 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Глюки накапливаются каким-то образом, сравнивать с VB, думаю, не коректно, хотябы потому, что VB создает exe-ик каждый раз заново. Когда я просил сравнить с VB - я имел ввиду размер, а не глюки 20 метров исходников - да не верю я что оно глючит так по черному как ты описываешь. По крайней мере с 15-тиметровыми исходниками я работал (мдб правда), ни одного объекта у меня за полтора года так и не схерилось. Данные - да, рушились, а само приложение - нет. Но, если обращаться к имени контрола на форме, то нифига. Их эти гады не могут этого сделать который год! Согласен. Гады. Но что делать.... хоть букву одну измени и вперед, пересоздавать головной ADE! Сомнения. Проверю. Кто значит не окно? В какой не в фокусе? В виднах все, что есть окна. Садись, двойка То, что у аксеса не в фокусе - ни фига не окно. Оно просто напросто картинка Дядя Гетц об этом писал. Надо читать дядю Гетца. А в принципе на некрупных проектах и не крупных базах, ADE очень неплох. Про MDB можно спокойно забыть. Тоскливо вздыхаю :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 20:14 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
у тебя клиенты - все разные? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 20:25 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
20 метров исходников - да не верю я что оно глючит так по черному как ты описываешь. По крайней мере с 15-тиметровыми исходниками я работал (мдб правда), ни одного объекта у меня за полтора года так и не схерилось. Данные - да, рушились, а само приложение - нет. аналогично... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 20:28 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
На всякий случай добавлю. Раз в неделю профилактические decompile/восстановить/сжать - и за полтора года ни одного схерившегося объекта. Усе. Пошел вотку пить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 20:33 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Раз в неделю профилактические decompile/восстановить/сжать А я все же предпочитаю новый проект или БД и импорт из старого. Думал, кстати, что АДП проеты не так мусор накапливают - нифига, то же самое как ни сжимай старый проект, начисто созданный все равно меньше... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.11.2003, 23:40 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Блин, ну вы как дети малые :-) А иногда Access, при правке и сохранении ADP пишет, "ошибка операции сохранения", это почти всегда значит все, до свидания, GoTo BackUp. Поэтому у нас в основном только импортом изменяют большие ADP. Поправишь такой файлик один раз ручками, попробуешь сохранить и кирдык. Может кто не понял, глюки появляются не во время работы ADE, а при правке. Если уж ADE один раз удачно создан, то работает нормально автор писал:То, что у аксеса не в фокусе - ни фига не окно. Оно просто напросто картинка Дядя Гетц об этом писал. Надо читать дядю Гетца. А картинка вообще-то тоже окно, если ты не знал:-). Врятли дядя так бы ошибка :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2003, 09:30 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Александр Иванов писал: писал:хоть букву одну измени и вперед, пересоздавать головной ADE! Проверил в XP. Теперь тяжкие мысли меня одолевают. Действительно пересоздавать ade. В случае mde та же бодяга. Причем в 97-м все было ок. Да... Видать в новых версиях изменения не только в лучшую сторону... Это конечно и так было известно, но такой западлянки я не ожидал... Александр Иванов писал: писал:А картинка вообще-то тоже окно, если ты не знал:-). Есть окно. А в нем есть картинка. Нарисована она там. DIB туда скопирован. И эта картинка тоже окно (отличное от родительского)? Да не смеши мои тапки. Лучше Гетца почитай ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2003, 15:03 |
|
||
|
Масштабируемость связки SQL сервер+ADP
|
|||
|---|---|---|---|
|
#18+
Блин, ну вы как дети малые :-) А иногда Access, при правке и сохранении ADP пишет, "ошибка операции сохранения", это почти всегда значит все, до свидания, GoTo BackUp. Поэтому у нас в основном только импортом изменяют большие ADP. Поправишь такой файлик один раз ручками, попробуешь сохранить и кирдык я так тоже маялся. пока при открытии /decompile не стал делать. и забыл про эти проблемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2003, 16:03 |
|
||
|
|

start [/forum/topic.php?all=1&fid=45&tid=1678427]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
60ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 244ms |
| total: | 427ms |

| 0 / 0 |
