1. Исправлены небольшие проблемы с совместимостью с MySQL 5.xx при регистрации новых пользователей.
2. Исправлена ошибка, при которой производилось автоматическое отключение вывода архива сайта, при отключении календаря.
3. Изменен алгоритм вывода даты у новостей и комментариев. Например если новость или комментарий были добавлены сегодня или вчера, то они выводятся в формате: " Сегодня, 12:34" или " Вчера, 12:34". В противном случае дата выводится в формате указанном в настройках скрипта. ...
Были подготовлены и реализованы следующие изменения:
1. Исправлены небольшие проблемы с совместимостью с MySQL 5.xx при регистрации новых пользователей.
2. Исправлена ошибка, при которой производилось автоматическое отключение вывода архива сайта, при отключении календаря.
3. Изменен алгоритм вывода даты у новостей и комментариев. Например если новость или комментарий были добавлены сегодня или вчера, то они выводятся в формате: " Сегодня, 12:34" или " Вчера, 12:34". В противном случае дата выводится в формате указанном в настройках скрипта.
4. Полностью переработан RSS экспорт на сайте. Добавлена возможность настраивать параметры экспорта из настроек скрипта. Также экспорт не использует больше шаблон rss.tpl необходимый формат формируется автоматически.
5. Добавлена возможность отключения RSS экспорта новостей в настройках скрипта, если вы не хотите использовать данную возможность, то можете отключить ее, тем самым будете экономить трафик сайта и предотвратите RSS граббинг ваших новостей.
6. Добавлена возможность выбора типа экспорта главного RSS канала сайта http://dle-news.ru/rss.xml вы можете экспортировать в него либо все новости, либо только опубликованные на главной странице.
7. В настройки скрипта добавлена возможность указания количества новостей, которые необходимо посылать в RSS поток.
8. Добавлена возможность выбора формата для RSS экспорта новостей. Есть три типа: первый тип это простой экспорт, при выборе этого типа вы сохраняете все преимущества RSS экспорта, но при этом из потока автоматически удаляется все форматирование текста, а также картинки, передается только сама суть новости, тем самым вы экономите траффик посетителей и усложняете RSS граббинг ваших новостей, т.к. те кто будет получать новости из вашего канала, будут получать только текст без форматирования. Второй формат это полный экспорт, при котором в поток будут передоватся ваши новости с сохранением полного форматирования и стилистики, т.е. как это было раньше. И последний формат экспорта, это передача ваших новостей в соответствии со спецификацией формата Яндекс новости, т.е. поток будет полностью соответствовать требованиям Яндекса, если вы хотите транслировать свои новости на их сайт.
9. Добавлено кеширование RSS экспорта, тем самым снижена нагрузка на MySQL сервер, т.к. этот модуль не использует запросов к MySQL серверу.
10. В связи с приобретением лицензии на одну очень интересную разработку (http://vikjavev.no/highslide/) было полностью изменено отображение оригинальной копии загруженного на сайт изображения. Отображение картинок производится в одном окне браузера, путем плавного увеличения. Пример вы можете посмотреть в этой новости, кликнув на уменьшенные копии загруженных изображений. В связи с тем что все новости хранятся в базе данных уже готовом, сформированном формате, то новая технология будет использоватся только в новых добавленных новостях. Если вы просто отредактируете старую новость, картинки в них будут увеличиваться также с использованием новой технологии.
11. Изменено отображение всплавающего окна уведомления о получении новых персональных сообщений. При отображении уведомления используются мягкие тени, работающие во всех браузерах.
12. Добавлена возможность при загрузке изображений на сервер, также вставить по одному клику оригинальное изображение, если для этого изображения была создана уменьшенная копия.
13. В модуль поиска добавлена возможность поиска определенного текста во всех комментариях. Кто не в курсе, то раньше поиск производился только в комментариях зарегистрированных пользователей.
14. Улучшена стабильность скрипта на некоторых NT системах.
15. Существенно расширена общая статистика сайта. Добавлен вывод количества опубликованных новостей за сутки, неделю, месяц (теги для шаблона stats.tpl {news_day}, {news_week}, {news_month} соответственно). Добавлен вывод количества добавленных комментариев за сутки, неделю, месяц (теги для шаблона stats.tpl {comm_day}, {comm_week}, {comm_month} соответственно). Добавлен вывод количества зарегистрированных пользователей за сутки, неделю, месяц (теги для шаблона stats.tpl {user_day}, {user_week}, {user_month} соответственно).
16. Добавлено кеширование модуля общей статистики сайта.
17. Добавлена автоматическая авторизация пользователей, после регистрации на сайте. Теперь после регистрации вашим посетителям не нужно вводить логин или пароль для входа на сайт, они будут автоматически распознаны скриптом.
18. Добавлена возможность автоматического создания бекапа вашей базы данных. Для функционирования данной возможности, необходима поддержка вашим хостером запуска приложений по CRON, это позволяет избежать нагрузки на сервер скриптом, а также вы можете самостояльно указать, когда создавать бекап базы данных и с какой периодичностью. Также вы можете указать количество одновременно хранимых на сервере резервных копий. Более старые копии БД будут автоматически удалятся.
19. Изменен принцип работы профиля пользователя. Теперь при просмотре профиля, в нем будут выводится только новости ожидающие модерации, и эти новости будут доступны для просмотра только их авторам и администраторам, для других пользователей, новости в профиле показыватся не будут. Но в данный шаблон добавлен тег {news} который выводит ссылку на просмотр всех опубликованных новостей данного пользователя. При переходе по данной ссылке будут показаны все новости пользователя, но уже без его профиля. Ссылка на просмотр всех новостей пользователя, опубликованных на сайте выглядит как http://site.ru/user/имя пользователя/news/
20. При нажатии ник автора новости добавлено удобное высплывающие меню, позволяющее перейти в его профиль, найти все его публикации, отправить персональное сообщение, а администраторы могут отредактировать его профиль.
21. Добавлена возможность указания в настройках скрипта краткого названия сайта, которое будет отображатся в модуле speedbar, вместо вашего основного названия сайта.
22. Изменен показ списка загруженных файлов в админпанели, если раньше после загрузки в списке показывалось количество скачиваний, то сейчас показывается размер файла. Иначе многие считали что 0 это размер и загрузка файла произошла со сбоем.
23. Добавлена возможность назначения собственного полностью отдельного от остальных шаблона для статических страниц.
24. Переработаны алгоритмы работы с RSS потоками, добавлена совместимость с последними версиями PHP 5.2.4 и выше (тем самым решена проблема возникновения ошибки: "XML error: not well-formed (invalid token)" на нормальных рабочих RSS потоках).
25. Переработан метод формирования ссылки на полную новость при включенном ЧПУ. Новый вид ссылки http://site.ru/категория/подкатегория/id-название новости.html Если новость не содержит категории то ссылка имеет вид http://site.ru/id-название новости.html. Благодаря новому формированию ссылки существенно снижается нагрузка на MySQL сервер, а также достигается лучшая поисковая оптимизация, т.к. при смене даты новости ее URL остается неизменным. Внимание новые ссылки формируются только для новых добавленных на сайт новостей, для старых новостей формируется старый вид ссылки, до тех пор пока вы неизмените дату у новости, тем самым полностью сохраняется поисковая оптимизация. Для примера вы можете посмотреть URL для данной новости на сайте http://dle-news.ru/ и URL более старых новостей.
26. Добавлена поддержка скриптом PHP версий 6.xx
27. Исправлена ошибка при которой происходила аварийная остановка загрузки файлов, если загружаемые файлы имели одинаковые имена.
28. Существенно сокращен траффик между БД MySQL и сервером, вследствии чего снижено потребление оперативной памяти и а также увеличена скорость работы скрипта.
29. Исправлены все обнаруженные и заявленные ранее небольшие ошибки в скрипте.
Многие мои друзья и знакомые часто спрашивают меня о том, как устроен мой сайт, сколько у меня таблиц в базе данных, как я храню данные и по каким полям веду поиск. Я, конечно, не выдаю все свои государственные тайны, но всегда понимаю причину таких вопросов и пытаюсь помочь людям построить быструю и надежную базу данных - т.е. тщательно продумать структуру БД таким образом, чтобы при увеличении нагрузки или объема таблиц динамический веб-сайт не превратился в тормозное усмертие.
А ведь многие новички (веб-строители) даже не догадываются о том, что крупные динамические сайты тормозят вовсе не из-за нагрузки скриптов на процессор, а в основном из-за неоптимизированного или дохленького MySQL-сервера. При этом во многом все зависит от того, как устроена ваша база данных.
Итак, начнем ликбез. Сразу всем вопрос: что делает MySQL во время записи в таблицы типа INSERT или UPDATE? Правильно - БЛОКИРУЕТ ТАБЛИЦЫ и пишет в них данные. Скорость записи и поиска может быть достаточно низкой, поэтому статус таблиц запрещает другим процессам считывать из них данные до окончания операции записи или обновления и снятия блокировки. При этом может получиться так, что во время записи единственного поля в длинные таблицы, ваш MySQL-сервер надолго заблокирует доступ к таблице остальным скриптам.
Например, вы создали таблицу новостей такого типа:
ID - номер, первичный ключ TEMA - тема новости MESS - сообщение, сама новость VIEWS - количество просмотров
При каждом обращении к новостям, скрипт будет выводить саму новость, а потом увеличивать поле VIEWS запросом UPDATE table 'NEWS' set VIEWS=VIEWS+1 where id=ID. При этом количество апдейтов будет довольно высоким. При высокой посещаемости веб-ресурса или при "нападении" на сайт поискового робота (эти ребята страдают многопоточностью и могут запросто повесить ваш сайт своими запросами) несколько одновременных процессов станут пытаться сделать UPDATE и SELECT. При каждом UPDATE таблица будет блокироваться (на это уходит время) и все остальные процессы будут ждать завершения операции. А если таблица достаточно большая? Например, несколько тысяч записей. Ежу понятно, что построится очередь из нескольких десятков скриптов, ожидающих ответа MySQL-сервера. Каждый будет жрать память и держать остальные процессы. В итоге все у вас зависнет и переглючит. Выход: делать вместо одной таблицы несколько. Советую разделять поля по типу их использования. Одну таблицу - только для вывода и редких обновлений или вставок. Другую - для частых обновлений, но редкого вывода. Например, значения счетчика обращений держать отдельно в таблицу вида:
ID - номер, первичный ключ VIEWS - количество просмотров
Сами новости лучше держать в другой таблице, где нет поля VIEWS. При этом таблица с новостями будет тяжелой (много текста, полей, индексов), а таблица COUNT (счетчик) будет очень легкой и быстрой. Таблица NEWS будет кешироваться и выводиться очень быстро при любых объемах, а таблица COUNT будет быстро обновляться из-за того, что она очень легкая (всего два целочисленных поля). Разделение данных по нескольким таблицам существенно ускоряет работу MySQL-сервера. Гораздо быстрее работают несколько мелких запросов по каждой таблице, чем один длинный запрос по одной или нескольким таблицам. Имейте это в виду, чтобы спать спокойно.
Дальше - круче. Чтобы не блокировать лишний раз свои таблицы используйте при вставках директиву DELAYED. Пример: INSERT DELAYED into STAT (ID,IP,UTIME) values (null,$ip,NOW()). Он позволяет серверу ответвлять поток в режиме ожидания, а саму вставку производить тогда, когда сервер освободится от других запросов или поступит следующий аналогичный INSERT DELAYED. Обычно отложенный метод подходит для любых операций с кумулятивными таблицами (когда в основном идут INSERTы, а данные копятся, а не модифицируются), при которых не особо важно когда именно подействуют изменения - мгновенно или через несколько секунд, минут. Например, если хотите собирать IPадреса своих посетителей, УРЛы, по которым они ходят или страницы, откуда пришли, время. При добавлении с задержкой скрипт отработает почти мгновенно, еще до выполнения операции.
Операция UPDATE идет в три этапа: поиск того, что будете менять, затем запись данных, обновление индексов. При этом, чем больше таблица, тем дольше поиск. Если есть индексы, то операция кешируется и выполняется достаточно быстро. Но сам процесс очень емкий. И только дурак не догонит, что большая таблица со множеством индексов и записей, будет тормозить при UPDATE. INSERT же выполняется одним залпом, очень быстро. Поэтому обычно используют аддитивные записи (вставками INSERT) во временные таблицы, потом блокируют основные талицы, суммируют обновления, и плюют их в основную таблицу. Получается, что в основном, главные таблицы работают только в режиме вывода, а обновления идут гораздо реже и быстрее. Например, можно копить данные о загрузках новостей во временной таблице, а по крону или иным образом обновлять счетчик каждые 10 минут (или реже). Это ускорит работу сервера.
При запросах SELECT * FROM таблица скрипт получит все поля данной таблицы. А нужно ли это? Использование * ведет к лишнему расходу ресурсов. Гораздо эффективнее использовать точные названия полей, которые нужны скрипту. Например: SELECT id,name FROM таблица. При таком запросе передача займет меньше времени и понадобится меньше ресурсов. Старайтесь ограничивать вывод при помощи директивы LIMIT. Это также ускоряет вывод.
Поиск по БД идет быстрее если вместо LIKE '%слово%', ставить 'слово%'. Операции с шаблонами регулярных выражений кешируются только в том случае, если в начале отсутствует символ %. Поэтому при построении поисковых запросов с LIKE избегайте начинающих символов %.
При построении таблиц для наиболее используемых полей (при поиске, сортировке и т.д.) обязательно создавайте индексы. Без индексов таблицы будут сильно тормозить. Индексы служат для кеширования и позволяют существенно ускорить вывод данных из таблиц. При этом таблицы будут занимать больше места на диске и в памяти. Но это в наше время не проблема.
Используйте надлежащий тип полей для своих записей. Тип TINYINT занимает 1 байт - самый быстрый. Таблицы с MEDIUMINT быстрее таблиц с INT. Если ставить полям свойство NOT NULL, то в целом их работа будет быстрее. VARCHAR медленее CHAR, поэтому таблицы переменной длины (где есть тип VARCHAR или TEXT) занимают меньше дискового пространства, но работают медленнее.
По своему опыту скажу, что для большинства сайтов подходят изложенные советы по работе с MySQL. Чтобы еще больше ускорить свой сервер, советую частоиспользуемые операции проводить по крону выделенными процессами и писать данные в различные файлы. Например, раз в 20 минут запускать скрипт, который будет создавать файл с новостями. Или например, генерить файл с новостями при их добавлениях или обновлениях. Таким образом, вы экономите на каждом обращении к БД. Интерактивность при этом не теряется, а производительность увеличивается во много раз. Особенно, повторяю, при высокой посещаемости ресурса. Старайтесь отделить интерактивные операции от фоновых. Например, на ПротоПлексе работает один интерактивный движок, но в фоне по заданиям трудятся с десяток различных роботов, которые генерируют часто вызываемые страницы, рассылают письма и т.д. Крупный сайт - это не только то, что вы видите, но и бек-енд (обратная сторона). В фоновом режиме можно быстро и эффективно готовить контент, освобождая основной движок от лишней работы.
В общем, основы должны быть всем понятны. Дробите все на мелочи, будь то запросы, таблицы или операции. Структура БД должна быть такой, чтобы не выполнялось ничего лишнего. Регулярно проводите OPTIMIZE на таблицах с переменной длиной, особенно, если в них идут удаления записей. Тестируйте свои запросы на скорость, упрощайте их.
Возникла необходимость програмно обращаться с определенному флеш-накопителю. Так как эти девайсы монтируются часто под разными буквами, в зависимости от порта, порядка подключения, начал искать варианты однозначного определения сабжа.
Изначально думал заставить монтироваться флешку всегда на одну-единственную букву, но к сожалению однозначного решения не нашел.
Поэтому решил определять эту букву по какому-нибудь ID устройства. Вот что получилось:
Информацию о подключенных флеш-накопителях можно получить например так (в EXCEL):
Эта статья является продолжением статьи о создании счетчика просмотров для каждой страницы сайта на php и MySQL (если Вы ее не читали, то обязательно прочтите, иначе ничего не поймете из ниже сказанного). В этой статья я решил продолжить тему и расширить возможности счетчика просмотров страниц.
Для увеличения возможностей и получения статистики просмотров страниц сайта к базовому php скрипту необходимо добавить несколько строк и своих функций. В частности нужно будет создать еще одну таблицу, которая имеет следующую структуру:
Как видно из структуры MySQL таблицы, она состоит всего из двух полей (page_id – хэш сумма md5() от urla страницы и page_url – url страницы) и индекса, установленного на поле page_id – для значительного ускорения поиска значения в таблице. И еще, я не стал изменять изначальную таблицу my_log, которая использовалась для подсчета количества просмотров страниц, а создал другую по одной простой, но очень весомой причине: чем больше данных в таблице – тем медленнее осуществляется поиск по таблице. А скорость работы php скриптов такого уровня не должна ощутимо влиять на работу сайта в целом. Ведь если у вас коммерческий и при этом очень посещаемый сайт, то тратить строго ограниченное процессорное время на второстепенные задачи просто невыгодно, ведь зачастую прибыль зависит от того, сколько человек сможет увидеть ваш сайт.
Теперь перейдем непосредственно к коду php скрипта. Я внес в него незначительные изменения, в основном это новые функции для работы с MySQL таблицей my_log_urls.
В counter.php внес следующие изменения:
добавляем функцию Default_Write_URL
В результате, получаем значительную экономию времени т.к. делаем всего одну запись в таблицу my_log_urls и одну в my_log, и при следующих запросах этой же страницы запрос к таблице my_log_urls выполняться не будет, т.к. запись уже существует в таблице my_log, следовательно и в таблице my_log_urls она то же есть.
Для подсчета рейтинга страниц сайта, предлагаю написать другой php скрипт, который будет по значениям просмотров страницы в таблице my_log брать значения в таблице my_log_urls. А результат представлять в виде таблицы с данными о просмотрах страниц, отсортированными по убыванию (от большего значения к меньшему).
Ниже приведен код php скрипта, который необходимо скопировать в созданный вами файл top.php:
Данный php скрипт выводит 10 самых популярных страниц вашего сайта за последние сутки и за все время. В принципе, можно осуществлять вывод и большего числа страниц, изменив в php функциях MySQLReadAll и MySQLReadToday лимит считываемых из таблицы записей. А так же можно вместо самых популярных страниц увидеть самые непопулярные, изменив способ сортировки в этих же функциях с DESC на ASC.
Скачать данный php скрипт, вместе с модифицированным php скриптом подсчета просмотров страниц, можно по этой ссылке.
На некоторых сайтах часто можно увидеть следующую надпись внизу страницы или под статьями: "Всего просмотров xxx. Сегодня xx". На первый взгляд ничего особенного, но все равно, многим интересно, как это сделано.
В этой статье я попробую рассказать вам о том, как устроена данная статистика просмотров страниц сайта, на самом простом примере, написанном на php. Статистика просмотров страниц будет работать на связке MySQL + PHP. Основным отличием этой статистики от других будет то, что MySQL таблица будет занимать очень мало места, но при этом нельзя будет точно сказать какую именно страницу и сколько раз просмотрели. А все из-за того, что все url будут хешированны с помощью php функции md5(), что гарантирует почти 100% неповторяющихся id для каждой страницы сайта. Делается это только для ускорения работы php скрипта (при условии, что индексом является id страницы) и уменьшения размеров MySQL таблицы (за счет отсутствия длинных url).
MySQL таблица будет иметь следующую структуру:
page_id – уникальный id для каждой страницы сайта сгенерированный php функцией md5().
all – значение всех просмотров данной страницы.
today – просмотров страницы сегодня.
date – дата возвращаемая php функцией time() + 24 часа
Для правильного учета посещений страниц значение поля date будет изменяться, тогда, когда текущая дата будет больше той, что указанна в таблице. В этот же момент будет происходить и обнуление счетчика просмотров страницы за прошедшие сутки.
Почти весь php скрипт статистики просмотров для каждой страницы сайта состоит в основном из функций, которые выполняют строго определенную роль. Все функции снабжены комментариями, поэтому, надеюсь, все поймете сами.
PHP код скрипта статистики просмотров страниц сайта:
Вот в принципе и весь php скрипт статистики просмотров страниц сайта. Для того, что бы он работал, его нужно "подключить" к нужному вам скрипту, например к index.php, добавив в index.php строчку include(' counter.php ');. А в том месте, где должно выводиться сообщение о том, сколько человек просмотрело данную страницу – строчку echo Today_and_all_counter;.
Скачать данный php скрипт статистики просмотров страниц сайта и MySQL файл со структурой таблицы можно здесь
Когда вы вызываете функцию Windows, она проверяет переданные ей параметры, а затем пытается выполнить работу. Если передан недопустимый параметр или если данную операцию нельзя выполнить по другой причине, она возвращает значение, свидетельствующее об ошибке. За каждой ошибкой закреплен свой 32 битный код. Функция Windows, обнаружив ошибку, через механизм локальной памяти потока сопоставляет соответствующий код ошибки с вызывающим потоком. Это позволяет потокам работать независимо друг от друга, не вмешиваясь в чужие ошибки.
Когда функция вернет вам управление, ее возвратное значение будет указывать на то, что произошла какая-то ошибка. Какая именно - вы узнаете, вызвав функцию GetLastError(). Она просто возвращает 32-битный код ошибки для данного потока. Список кодов ошибок, определенных Microsoft, содержится в файле WinError.h.
Функцию GetLastError необходимо вызывать сразу же за проверяемой функцией, иначе код ошибки будет утерян.
Для отладки бывает нужно следить не за одной ошибкой , а за их постоянным изменением, для этого нет необходимости включать в код постоянные проверки и чтение GetLastError, можно в окне дебагирования Visual C++ ввести @err,hr. В окне вы увидите значение переменной ошибки.
Так как ошибки, которые возникают в программе, возникают не только в процессе отладки, но могут быть обусловлены текущим состоянием системы, на которй бежит программа, то иногда бывает полезно сообщить тип ошибки в нормальном текстовом виде.
В Windows есть специальная функция, которая "конвертирует" код ошибки в ее описание, - FormatMessage.
Для разработчика особенно важно, при создании API или SDK подобных вещей, создавать сходный механизм возврата ошибок для своих функций.
С этой целью вы просто устанавливаете код последней ошибки в потоке и возвращаете значение FALSE, INVALID_HANDLE_VALUE, NULL или что-то другое, более подходящее по ситуации. Чтобы установить код последней ошибки в потоке используйте SetLastError.
Параметр - 32-битное число. Использовать лучше подходящий код ошибки Windows, однако если такового подходящего не нашлось, то можно ввести свой собственный код ошибки. Он должен представлять собой 32-битное число, разбитое по следующим правилам.
Биты
31-30 - Код тяжести - 0=успех, 1=информация, 2=предупреждение, 3=ошибка
29 - Кем определен - 0-Microsoft 1-пользователем
28 - Должен быть 0
27-16 - Определяется Microsoft. (Код подсистемы)
15-0 - Код ошибки.
Собственно Microsoft обещает, что бит 29 будет в ее ошибках всегда равен 0 поэтому, поставив там 1, вы будете в какой-то степени в безопасности от конфликтов с кодами ошибок Microsoft.
Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах. На практике это означает, что потоки исполняют код и манипулируют данными в адресном пространстве процесса. Если два или более потока выполняются внутри одного процесса, они делят одно адресное пространство.
Любой поток (thread) состоит из двух компонентов:
объекта ядра, через который ОС управляет потоком. Там же хранится статистическая информация о потоке.
Стека потока, который содержит параметры всех функций и локальные переменные, необходимые потоку для выполнения кода.
Потоки могут выполнять один и тот же код, манипулировать одними и теми же данными, а также совместно использовать описатели объектов ядра, поскольку таблица описателей создается не в отдельных потоках, а в процессах.
Потоки используют намного меньше ресурсов системы, чем процессы, поэтому все задачи, требующие параллельного выполнения нескольких подзадач, стоит решать по возможности с помощью потоков, не прибегая к созданию нескольких процессов.
Обычная структура многопоточного приложения рассчитана на одновременное исполнение нескольких подзадач. Однако стоит помнить, что, создавая многопоточное приложение, нам придется заботиться о сохранности и ликвидности, общих для всех потоков, данных.
Создание потока.
Первичный поток, который присутствует в программе, начинает свое выполнение с главной функции потока типа WinMain.
Для создания вторичного потока необходимо создать и для него входную функцию, которая выглядит примерно так:
Имя у функции вторичного потока, в отличии от первичного, может быть любым однако, при наличии нескольких разных потоков, назвать функции необходимо по-разному, иначе система создаст разные реализации одной и той же функции.
Когда поток закончит свое исполнение, он вернет управление системе, память, отведенная под его стек, будет освобождена, а счетчик пользователей его объекта ядра "поток" уменьшится на 1. Когда счетчик обнулится, этот объект ядра будет разрушен.
Для создания своего потока необходимо использовать функцию CreateThread:
При каждом вызове этой функции система создает объект ядра (поток). Это не сам поток, а компактная структура данных, которая используется операционной системой для управления потоком и хранит статистическую информацию о потоке.
Система выделяет память под стек потока из адресного пространства процесса. Новый поток выполняется в контексте того же процесса, что и родительский поток. Поэтому он получает доступ ко всем описателям объектов ядра, всей памяти и стекам всех потоков в процессе. За счет этого потоки в рамках одного процесса могут легко взаимодействовать друг с другом.
CreateThread - это Windows-функция, создающая поток. Если вы пишете код на С/С++ не вызывайте ее. Вместо нее Вы должны использовать _beginthreadex из библиотеки Visual C++. Почему это так важно в наших следующих выпусках.
Параметры функции CreateThread.
LpThreadAttributes - является указателем на структуру LPSECURITY_ATTRIBUTES. Для присвоения атрибутов защиты по умолчанию, передавайте в этом параметре NULL.
DwStackSize - параметр определяет размер стека, выделяемый для потока из общего адресного пространства процесса. При передаче 0 - размер устанавливается в значение по умолчанию.
LpStartAddress - указатель на адрес входной функции потока.
LpParameter - параметр, который будет передан внутрь функции потока.
DwCreationFlags - принимает одно из двух значений: 0 - исполнение начинается немедленно, или CREATE_SUSPENDED - исполнение приостанавливается до последующих указаний.
LpThreadId - Адрес переменной типа DWORD в который функция возвращает идентификатор, приписанный системой новому потоку.
Завершение потока
Поток можно завершит четырьмя способами:
функция потока возвращает управление (рекомендуемо);
поток самоуничтожается вызовом функции ExitThread;
другой поток процесса вызывает функцию TerminateThread;
завершается процесс, содержащий данный поток.
Все способы , за исключением рекомендуемого, являются нежелательными и должны использоваться только в форс-мажорных обстоятельствах.
Функция потока, возвращая управление, гарантирует корректную очистку всех ресурсов, принадлежащих данному потоку. При этом:
любые С++ объекты, созданные данным потоком, уничтожаются соответствующими деструкторами;
система корректно освобождает память, которую занимал стек потока;
система устанавливает код завершения данного потока. Его функция и возвращает;
счетчик пользователей данного объекта ядра (поток) уменьшается на 1.
При желании немедленно завершить поток изнутри используют функцию ExitThread(DWORD dwExitCode).
При этом освобождаются все ресурсы ОС, выделенные данному потоку, но С С++ ресурсы (например, объекты классов С++) не очищаются. Именно поэтому не рекомендовано завершать поток, используя эту функцию.
Если же вы ее использовали, то кодом возврата потока будет тот параметр, который вы передадите в данную функцию.
Как и для CreateThread для библиотеки Visual C++ существует ее аналог _endthreadex, который и стоит использовать. Об причинах в следующем выпуске.
Если появилась необходимость уничтожить поток снаружи, то это моет сделать функция TeminateThread.
Эта функция уменьшит счетчик пользователей объекта ядра (поток) на 1, однако при этом не разрушит и не очистит стек потока. Стек будет существовать, пока не завершится процесс, которому принадлежит поток. При задачах, постоянно создающих и уничтожающих потоки, это приводит к потере памяти внутри процесса.
При завершении процесса происходит следующее.
Завершение потока происходит принудительно. Деструкторы объектов не вызываются, и т.д. и т.д.
При завершении потока по такой причине, связанный с ним объект ядра (поток) не освобождается до тех пор, пока не будут закрыты все внешние ссылки на этот объект.
В состав библиотеки MFC входит ряд классов, представляющих стандартные диалоговые панели. Эти классы позволяют легко реализовать такие часто используемые операции, как открытие и сохранение файла, выбор цвета, выбор шрифта и т.д. Все эти классы наследуются от CCommonDialog, который в свою очередь является производным по отношению к базовому классу CDialog.
Приведем классы стандартных диалоговых панелей и их назначение:
CColorDialog - Панель для выбора цвета
CFileDialog - Панель выбора файлов для открытия и сохранения на диске
CFindReplaceDialog - Панель для выполнения операции поиска и замены
CFontDialog - Панель для выбора шрифта
CPrintDialog - Панель для вывода документа на печать
CPageSetupDialog - Панель выбора формата документа
COleDialog - Панель для управления технологией OLE
Классы, управляющие стандартными диалоговыми панелями, определены в файле afxdlgs.h. Поэтому при использовании этих классов в приложении необходимо включить этот файл в исходный текст при помощи директивы #include.
Панель выбора цвета (класс CColorDialog)
Чтобы отобразить на экране стандартную диалоговую панель выбора цвета, надо создать объект класса CColorDialog, а затем вызвать метод DoModal. При создании объекта класса СColorDialog используется следующий конструктор:
Все параметры конструктора необязательны, однако в некоторых случаях использование этих параметров может помочь.
Первый параметр clrInit позволяет указать цвет, выбранный по умолчанию сразу после открытия диалоговой панели. Если параметр не будет указан, в качестве цвета, выбранного по умолчанию, будет использоваться черный цвет.
Параметр dwFlags содержит набор флагов, управляющих диалоговой панелью выбора цвета. При помощи него блокировать или разрешать работу некоторых элементов управления диалоговой панели выбора цвета. Если при создании объекта класса CColorDialog не указать параметр dwFlags, тем не менее можно выполнить настройку диалоговой панели, обратившись непосредственно к элементу m_cc данного класса. Параметр dwFlags, указанный в конструкторе, используется для инициализации m_cc. Изменения в элемент m_cc должны быть внесены до того, как панель будет отображаться на экране.
Последний параметр pParentWnd можно использовать, чтобы указать родительское окно диалоговой панели.
Методы класса CСolorDialog
Чтобы вывести диалоговую панель выбора цвета на экран, необходимо использовать метод DoModal. После отображения панели на экране пользователь может выбрать из нее цвет и нажать кнопки OK или Cancel для подтверждения выбора цвета или отказа от него. Когда диалоговая панель закрывается, метод DoModal возвращается значения IDOK и IDCANCEL, в зависимости от того, какую кнопку нажал пользователь:
На экране появится стандартная диалоговая панель выбора цвета Color. В верхней половине диалоговой панели расположены 48 прямоугольников, имеющих различные цвета. Они представляют так называемые основные цвета (Basic colors). Можно выбрать один из этих цветов и нажать кнопку OK. После того, как диалоговая панель закрыта (метод DoModal завершил свою работу), можно воспользоваться методами класса CColorDialog, чтобы узнать цвета, выбранные пользователем.
Для определения цвета, выбранного пользователем, можно обратиться к методу GetColor класса CColorDialog. Данный метод возвращает значение COLORREF, соответствующее выбранному цвету.
Если пользователю недостаточно основных цветов, представленных в диалоговой панели Color, он может выбрать до 16 дополнительных цветов. Для этого он должен нажать кнопку DefineCustom Colors. Диалоговая панель изменит свой внешний вид - появятся дополнительные органы управления, позволяющие выбрать любой из 16 777 216 цветов. Когда цвет выбран, нужно нажать кнопку Add Custom Colors. Выбранный цвет будет добавлен к дополнительным цветам (Custom colors) - один из свободных прямоугольников окрасится соответствующим цветом.
При помощи метода GetSavedCustomColors класса CColorDialog можно определить дополнительные цвета, выбранные пользователем в диалоговой панели Color. Этот метод возвращает указатель на массив из 16 элементов типа COLORREF. Каждый элемент массива описывает один дополнительный цвет.
Когда диалоговая панель Color отображается приложением первый раз, все прямоугольники, отображающие дополнительные цвета, имеют белый цвет. Дополнительные цвета, выбранные пользователем, сохраняются во время работы приложения. После перезапуска приложения дополнительные цвета сбрасываются.
Панель выбора файлов (класс CFileDialog)
Среди стандартных диалоговых панелей, для которых в библиотеке MFC создан специальный класс, есть панели для работы с файловой системой - Open и Save As. Диалоговая панель Open позволяет выбрать один или несколько файлов и открыть их для дальнейшего использования. Диалоговая панель Save As позволяет выбрать имя файла для записи в него документа.
Для управления диалоговыми панелями Open и Save As предназначен один класс CFileDialog. Рассмотрим конструктор класса CFileDialog более подробно:
Объекты класса CFileDialog представляют диалоговые панели Open или Save As в зависимости от параметра bOpenFileDialog. Если параметр bOpenFileDialog содержит значение TRUE, то создается объект, управляющий диалоговой панелью Open, а если FALSE - диалоговой панелью Save As.
Параметр bOpenFileDialog является единственным обязательным параметром, который необходимо указать. Остальные параметры конструктора класса CFileDialog задают различные режимы работы панели и могут не указываться.
Чтобы создать объект класса CFileDialog , представляющий диалоговую панель для открытия файлов (mFileOpen), и объект, представляющий диалоговую панель для сохранения файлов (mFileSaveAs), можно воспользоваться следующими вызовами конструктора класса:
Во многих случаях имена файлов, которые нужно открыть или закрыть, имеют определенное расширение. Параметр lpszDefExt позволяет задать расширение файлов, используемое по умолчанию. То есть, если пользователь при определении имени файла не укажет расширение, имени файла автоматически присваивается расширение, принятое по умолчанию. Если при определении свойств диалоговой панели программист присвоит параметру lpszDefExt значение NULL, то расширение файлов должно задаваться пользователем явно.
В некоторых случаях требуется, чтобы диалоговые панели отображались с уже выбранным именем файла. Чтобы указать имя файла, используемое по умолчанию, применяется параметр lpszFileName. Если параметр lpszFileName имеет значение NULL, данная возможность не реализуется.
С помощью флага dwFlags можно изменить внешний вид и некоторые другие характеристики стандартных диалоговых панелей класса CFileDialog. В него можно записать комбинацию флагов, управляющих различными характеристиками этих панелей. Например, флаг OFN_HIDEREADONLY означает, что из диалоговой панели удаляется переключатель "Read Only", а флаг OFN_OVERWRITEPROMPT (используемый для панели Save As) - что необходимо выводить диалоговую панель с предупреждением, если пользователь выбирает для сохранения имя уже существующего файла.
Диалоговые панели выбора файлов обычно имеют список так называемых фильтров, включающих названия типов файлов и расширения имен файлов данного типа. Выбрав фильтр, пользователь указывает, что он желает работать только с файлами определенного типа, имеющими соответствующее расширение. Файлы с другими расширениями в диалоговых панелях не отображаются.
Список фильтров можно указать через параметр lpszFilter. Одновременно можно указать несколько фильтров. Каждый фильтр задается двумя строками - строкой, содержащей имя фильтра, и строкой, в которой перечислены соответствующие ему расширения имен файлов. Если одному типу соответствует несколько расширений, они разделяются символом ;. Строка, содержащая имя фильтра, отделяется от строки с расширениями файлов символом |. Если используется несколько фильтров, то они также отделяются друг от друга символом |. Например, в качестве строки, задающей фильтры, можно использовать строку вида:
Диалоговые панели, представленные объектами класса CFileDialog, могут иметь или не иметь родительского окна. Чтобы указать родительское окно, нужно передать конструктору CFileDialog указатель на него через параметр pParentWnd.
Методы класса CFileDialog
Создание объекта класса CFileDialog еще не вызывает отображения соответствующей диалоговой панели. Для этого необходимо воспользоваться методом DoModal класса CFileDialog.При вызове метода DoModal для ранее созданного объекта класса CFileDialog на экране открывается соответствующая диалоговая панель. После того, как пользователь завершает работу с диалоговой панелью, метод DoModal вернет значение IDOK или IDCANCEL в случае успешного завершения и нуль - в случае возникновения ошибок:
После того, как пользователь закроет диалоговую панель и метод DoModal вернет управление, можно воспользоваться другими методами класса CFileDialog , чтобы определить имена выбранных файлов:
GetPathName - Определяет полный путь файла
GetFileName - Определяет имя выбранного файла
GetFileExt - Определяет расширение имени выбранного файла
GetFileTitle - Позволяет определить заголовок выбранного файла
GetNextPathName - Если диалоговая панель позволяет выбрать сразу несколько файлов, то этот метод можно использовать для определения полного пути следующего из выбранных файлов
GetReadOnlyPref - Позволяет узнать состояние атрибута "только для чтения" (read-only) выбранного файла
GetStartPosition - Возвращает положение первого элемента из списка имен файлов
Наиболее важный метод - GetPathName. Он получает полный путь файла, выбранного из диалоговых панелей Open или Save As. Если диалоговая панель позволяет выбрать сразу несколько файлов, тогда метод GetPathName возвращает массив строк, состоящий из нескольких строк, заканчивающихся двоичным нулем. Первая из данных строк содержит путь к каталогу, в котором расположены выбранные файлы, остальные строки содержат имена выбранных файлов. Выделение строки, содержащей путь к каталогу, проблем не вызывает, а чтобы получить имена выбранных файлов, необходимо воспользоваться методами GetStartPosition и GetNextPathName.
[pagebreak]
Метод GetStartPosition возвращает значение типа POSITION. Оно предназначено для передачи методу GetNextPathName и получения очередного имени выбранного файла. Если пользователь не выбрал ни одного файла, метод GetStartPosition возвращает значение NULL. Значение, полученное этим методом, следует записать во временную переменную типа POSITION и передать ссылку на нее методу GetNextPathName. Метод GetNextPathName вернет полный путь первого из выбранных в диалоговой панели файлов и изменит значение переменной pos, переданной методу по ссылке. Новое значение pos можно использовать для последующих вызовов метода GetNextPathName и получения путей всех остальных выбранных файлов. Когда метод GetNextPathName вернет имена всех выбранных файлов, в переменную pos записывается значение NULL.
В панелях Open и Save As имеется переключатель "ReadOnly". По умолчанию этот преключатель не отображается. Если есть необходимость воспользоваться этим переключателем, то нужно отказаться от использования флага OFN_HIDEREADONLY.
Метод GetReadOnlyPref позволяет определить положение переключателя "ReadOnly". Если переключатель включен, то метод GetReadOnlyPref возвращает ненулевое значение. В противном случае GetReadOnlyPref возвращает нуль.
Панель выбора шрифта (класс CFontDialog)
Стандартная диалоговая панель Font предназначена для выбора шрифта. Эта панель отображает список шрифтов, установленных в системе, и позволяет выбрать название шрифта, его начертание и другие параметры.
Для управления диалоговой панелью Font в библиотеку классов MFC включен класс CFontDialog. Методы этого класса можно использовать для отображения панели Font и определения характеристик шрифта, выбранного пользователем. Конструктор класса CFontDialog:
Все параметры конструктора являются необязательными. Настройка стандартной панели выбора шрифта, которая выполняется конструктором класса CFontDialog по умолчанию, удовлетворяет большинству пользователей.
Параметр lplfInitial является указателем на структуру LOGFONT, описывающую логический шрифт. Если этот параметр используется, то в диалоговой панели по умолчанию будет выбран шрифт, наиболее соответствующий шрифту, описанному в структуре LOGFONT.
Параметр dwFlags задает набор флагов, управляющий различными режимами работы панели. Например, флаг CF_EFFECTS позволяет пользователю создавать подчеркнутые и перечеркнутые буквы, определять цвет букв, а флаг CF_SCREENFONTS - разрешает выбирать только экранные шрифты.
Через параметр pdcPrinter можно передать конструктору контекст отображения принтера, шрифты которого будут представлены в диалоговой панели Font. Данный параметр используется только в том случае, если в параметре dwFlags указаны флаги CF_PRINTERFONTS или CF_BOTH.
Через параметр pParentWnd можно указать родительское окно для диалоговой панели Font.
Методы класса CFontDialog
Для отображения диалоговой панели Font предназначен виртуальный метод DoModal. Если пользователь выбрал шрифт и нажал кнопку OK, метод DoModal возвращает идентификатор IDOK, если пользователь отменил выбор шрифта, метод DoModal возвращает идентификатор IDCANCEL:
Остальные методы класса предназначены для определения характеристик выбранного пользователем шрифта.
Метод GetCurrentFont позволяет сразу определить все характеристики выбранного шрифта, записав их в структуру LOGFONT.
Остальные методы класса позволяют определить только отдельные характеристики выбранного шрифта:
GetFaceName - Возвращает имя выбранного шрифта
GetStyleName - Возвращает имя стиля выбранного шрифта
GetSize - Возвращает размер выбранного шрифта
GetColor - Возвращает цвет выбранного шрифта
GetWeight - Возвращает плотность выбранного шрифта
IsStrikeOut - Определяет, является ли шрифт выделенным перечеркнутой линией
IsUnderline - Определяет, является ли шрифт выделенным подчеркиванием
IsBold - Определяет, является ли шрифт жирным
IsItalic - Определяет, является ли шрифт наклонным
Панель для вывода документов на печать (класс CPrintDialog)
Класс CPrintDialog можно использовать для создания двух видов диалоговых панелей, предназначенных для печати документов и выбора форматов документов. Кроме класса CPrintDialog можно также использовать класс CPageSetupDialog. Он позволяет создать диалоговую панель для выбора формата документа, имеющую несколько иной вид.
В приложениях, подготовленных с использованием средств MFC AppWizard и построенные по модели документ-облик, по умолчанию встроена возможность вывода редактируемого документа на печать.
В меню File такого приложения находятся три строки (Print, Print Preview и Print Setup), которые управляют процессом печати документов, подготовленных в приложении. Чтобы распечатать документ, достаточно выбрать из меню File строку Print. На экране появится диалоговая панель Print. В ней можно выбрать печатающее устройство для печати документов (группа Name), указать, будет печататься весь документ либо его часть (группа Print range), а также сколько копий документа будет напечатано (группа Copies). Также можно настроить различные характеристики печатающего устройства, если нажать кнопку Properties в группе Printer.
Если требуется определить только печатающее устройство и формат документа, из меню File следует выбрать строку Printer Setup. В группе Printer можно указать печатающее устройство и настроить его соответствующим образом. Группа Paper задает формат бумаги и режим подачи бумаги в печатающее устройство. Группа Orientation включает только один переключатель, определяющий ориентацию бумаги. Он принимает положение Portrait для вертикальной ориентации изображения на бумаге (режим "портрет") или Landscape для горизонтальной ориентации изоборажения на бумаге (режим "ландшафт").
Строка Print Preview меню File выбирается для предварительного просмотра документа перед печатью. При этом главное окно приложения изменит свой внешний вид и можно будет просмотреть, как будет выглядеть документ после печати.
Если не требуется выполнять специфическую обработку документа перед печатью, то вряд ли понадобится самостоятельное добавление программного кода, отвечающего за процесс печати. Просто следует отметить, что процедура создания панелей, связанных с печатью документа, практически ничем не отличается от создания выше описанных стандартных диалоговых панелей.
Панель для выполнения поиска и замены (класс CFindReplaceDialog)
Класс CFindReplaceDialog предназначен для управления диалоговыми окнами Find и Replace. Диалоговая панель Find используется для поиска известных строк в документе приложения, а панель Replace позволяет замену одной строки на другую.
Важным отличием диалоговых панелей Find и Replace от других стандартных диалоговых панелей является то, что они представляют собой немодальные диалоговые панели. Поэтому процесс создания этих панелей значительно отличается от процесса создания стандартных панелей для выбора цвета, шрифта и имен файла.
Когда пишут про сокетное программирование, конечно же, подразумевается TCP/IP. Вот тут мы и отступим от правил, поговорим про IPX/SPX.
А все начинается как всегда, а именно, с инициализации WINSOCK библиотеки, обработка ошибок упускается для упрощения кода:
Ну и собственно сокет, тут я дам только кусок, отличный от нормальных сокетов:
В остальном, работа с SPX идентична работе TCP сокетов, все выше написанное справедливо и для IPX сокетов, только не забудьте, что последние нельзя законнектить. Открываются они следующим образом:
Передача данных происходит следующим образом:
Дальше я дам несколько, на мой взгляд, полезных вещей при работе с данными протоколами.
Приём заголовка пакета данных
В некоторых случаях нам нужен больший контроль над IPX/SPX пакетами, и для того, чтоб наше приложение могло управлять, изменять заголовок IPX/SPX, нужно вызвать следующий код:
А вот вам и структура заголовка SPX пакета, взято из WSIPX.H
В данном режиме Windows Sockets не будут сегментировать пакеты, ограничивая их размер до максимально допустимого протоколом.
Широковещательные пакеты
Широковещательные пакеты могут быть использованы, например, в качестве средства "принюхивания" клиента к серверу, это в случае, когда мы знаем порт нужного нам сервера, но не знаем его сетевого адресса.
Установка, изменение DataStreamType в заголовке SPX пакета
Это может быть использовано в собственных целях, например, для искусственной сегментации своих данных для совместимости разных реализаций протокола. Например, некоторые реализации протокола для DOS поддерживают максимальную длину пакета в 512 байт либо принудительно ограниченную сетевыми модулями, вот они и используют DataStreamType, чтобы указать последнюю порцию данных.
Устанавливается следующим образом:
Причём данную установку надо делать перед каждым send. Работает всё ОК, когда посылаются данные ДОС клиенту, ну а при приеме пакетов WIN клиентом от ДОС клиент DataStreamType не хочет устанавливатся, т.е. мы не получим установленное значение DataStreamType ДОС клиентом. Я обошел данную проблему при помощи следующего куска кода:
Данный метод хорош еще тем, что WIN клиент может принять один пакет вместо нескольких, посланных ДОС клиентом.
Другие специфические расширения для данных протоколов, используемые getsockopt/setsockopt, можно найти в файле wsnwlink.h, но, как упоминалось выше, данные расширения - для NT-платформ и могут не работать для других реализаций данных протоколов.
В этой статье приведу пример реализации древовидного меню на JavaScript с помощью PHP.
В своей практике много раз сталкивался с тем, что такое меню нужно, но человек затрудняется соединить скрипт на PHP с меню скриптом на JavaScript.
Для примера возьмём бесплатный скрипт для отображения древовидного меню Tigra Tree Menu, который поддерживается: MS IE, Netscape на платформах Windows 95/98/ME/2000/XP и Mac OS 8/9/X по адресу http://www.softcomplex.com/products/tigra_tree_menu/
Скачав и распаковав архив, мы увидим 3 яваскриптовых файла:
tree.js (сам скрипт отображения и формирования меню), tree_tpl.js(настройки самого меню и картинок к нему), а также
tree_items.js (сама структура меню), который нам и нужно заменить на PHP скрипт, который возьмёт наши данные из базы.
Создайте таблицу в базе данных:
id - идентификатор пункта меню;
pid - принадлежность к ветке меню (если, например, pid = 12, значит, этот пункт является подуровнем пункта, у которого id = 12);
name - название самого пункта меню.
Ну, и заполним немного данными для демонстрации:
Далее соединимся с базой данных и напишем рекурсивную функцию для формирования такой структуры, как в файле tree_items.js.
Пишем саму функцию:
Теперь в нужном нам месте выводим сформированное меню:
P.S. Для того, чтобы меню работало, не забудьте на странице, сразу после тега < body >, вставить нужные скрипты "Tigra Tree Menu":
Ну вот и всё. Надеюсь, что кому-нибудь это пригодится.
Для программирования расширенных хранимых процедур Microsoft предоставляет ODS (Open Data Service) API набор макросов и функций, используемых для построения серверных приложений позволяющих расширить функциональность MS SQL Server 2000.
Расширенные хранимые процедуры - это обычные функции написанные на С/C++ с применением ODS API и WIN32 API, оформленные в виде библиотеки динамической компоновки (dll) и призванные, как я уже говорил, расширять функциональность SQL сервера. ODS API предоставляет разработчику богатый набор функций позволяющих передавать данные клиенту, полученные от любых внешних источников данных (data source) в виде обычных наборов записей (record set). Так же, extended stored procedure может возвращать значения через переданный ей параметр (OUTPUT parametr).
Как работают расширенные хранимые процедуры.
* Когда клиентское приложение вызывает расширенную хранимую процедуру, запрос передаётся в TDS формате через сетевую библиотеку Net-Libraries и Open Data Service ядру MS SQL SERVER.
* SQL Sever находит dll библиотеку ассоциированную с именем расширенной хранимой процедуры и загружает её в свой контекст, если она не была загружена туда ранее, и вызывает расширенную хранимую процедуру, реализованную как функцию внутри dll.
* Расширенная хранимая процедура выполняет на сервере необходимые ей действия и передаёт набор результатов клиентскому приложению, используя сервис предоставляемый ODS API.
Особенности расширенных хранимых процедур.
* Расширенные хранимые процедуры - это функции выполняющиеся в адресном пространстве MS SQL Server и в контексте безопасности учётной записи под которой запущена служба MS SQL Server;
* После того, как dll библиотека с расширенными хранимыми процедурами была загружена в память, она остаётся там до тех пор, пока SQL Server не будет остановлен, или пока администратор не выгрузит её принудительно, используя команду :
DBCC DLL_name (FREE).
* Расширенная хранимая процедура запускается на выполнение так же, как и обычная хранимая процедура:
EXECUTE xp_extendedProcName @param1, @param2 OUTPUT
@param1 входной параметр
@param2 входной/выходной параметр
Внимание!
Так как расширенные хранимые процедуры выполняются в адресном пространстве процесса службы MS SQL Server, любые критические ошибки, возникающие в их работе, могут вывести из строя ядро сервера, поэтому рекомендуется тщательно протестировать Вашу DLL перед установкой на рабочий сервер.
Создание расширенных хранимых процедур.
Расширенная хранимая процедура эта функция имеющая следующий прототип:
Параметр pSrvProc указатель на SRVPROC структуру, которая является описателем (handle) каждого конкретного клиентского подключения. Поля этой структуры недокументированны и содеражат информацию, которую библиотека ODS использует для управления коммуникацией и данными между серверным приложением (Open Data Services server application) и клиентом. В любом случае, Вам не потребуется обращаться к этой структуре и тем более нельзя модифицоравать её. Этот параметр требуется указывать при вызове любой функции ODS API, поэтому в дальнейшем я небуду останавливаться на его описании.
Использование префикса xp_ необязательно, однако существует соглашение начинать имя расширенной хранимой процедуры именно так, чтобы подчеркнуть отличие от обычной хранимой процедуры, имена которых, как Вы знаете, принято начинать с префикса sp_.
Так же следует помнить, что имена расширенных хранимых процедур чувствительны к регистру. Не забывайте об этом, когда будете вызвать расширенную хранимую процедуру, иначе вместо ожидаемого результата, Вы получите сообщение об ошибке.
Если Вам необходимо написать код инициализации/деинициализации dll, используйте для этого стандартную функцию DllMain(). Если у Вас нет такой необходимости, и вы не хотите писать DLLMain(), то компилятор соберёт свою версию функции DLLMain(), которая ничего не делает, а просто возвращает TRUE. Все функции, вызываемые из dll (т.е. расширенные хранимые процедуры) должны быть объявлены, как экспортируемые. Если Вы пишете на MS Visual C++ используйте директиву __declspec(dllexport). Если Ваш компилятор не поддерживает эту директиву, опишите экспортируемую функцию в секции EXPORTS в DEF файле.
Итак, для создания проекта, нам понадобятся следующие файлы:
* Srv.h заголовочный файл, содержит описание функций и макросов ODS API;
* Opends60.lib файл импорта библиотеки Opends60.dll, которая и реализует весь сервис предоставляемый ODS API.
Microsoft настоятельно рекомендует, чтобы все DLL библиотеки реализующие расширенные хранимые процедуры экспортировали функцию:
Когда MS SQL Server загружает DLL c extended stored procedure, он первым делом вызывает эту функцию, чтобы получить информацию о версии используемой библиотеки.
Для написания своей первой extended stored procedure, Вам понадобится установить на свой компьютер:
- MS SQL Server 2000 любой редакции (у меня стоит Personal Edition). В процесе инсталляции обязательно выберите опцию source sample
- MS Visual C++ (я использовал версию 7.0 ), но точно знаю подойдёт и 6.0
Установка SQL Server -a нужна для тестирования и отладки Вашей DLL. Возможна и отладка по сети, но я этого никогда не делал, и поэтому установил всё на свой локальный диск. В поставку Microsoft Visual C++ 7.0 редакции Interprise Edition входит мастер Extended Stored Procedure DLL Wizard. В принципе, ничего сверх естественного он не делает, а только генерирует заготовку шаблон расширенной хранимой процедуры. Если Вам нравятся мастера, можете использовать его. Я же предпочитаю делать всё ручками, и поэтому не буду рассматривать этот случай.
Теперь к делу:
- Запустите Visual C++ и создайте новый проект - Win32 Dynamic Link Library.
- Включите в проект заголовочный файл - #include <srv.h>;
- Зайдите в меню Tools => Options и добавьте пути поиска include и library файлов. Если , при установке MS SQL Server, Вы ничего не меняли, то задайте:
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsInclude для заголовочных файлов;
- C:Program FilesMicrosoft SQL Server80ToolsDevToolsLib для библиотечных файлов.
- Укажите имя библиотечного файла opends60.lib в опциях линкера.
На этом подготовительный этап закончен, можно приступать к написанию своей первой extended stored procedure.
Постановка задачи.
Прежде чем приступать к программированию, необходимо чётко представлять с чего начать, какой должен быть конечный результат, и каким способом его добиться. Итак, вот нам техническое задание:
Разработать расширенную хранимую процедуру для MS SQL Server 2000, которая получает полный список пользователей зарегистрированных в домене, и возвращает его клиенту в виде стандартного набора записей (record set). В качестве первого входного параметра функция получает имя сервера содержащего базу данных каталога (Active Directory), т.е имя контролера домена. Если этот параметр равен NULL, тогда необходимо передать клиенту список локальных групп. Второй параметр будет использоваться extended stored procedure для возварата значения результата успешной/неуспешной работы (OUTPUT параметр). Если, расширенная хранимая процедура выполнена успешно, тогда необходимо передать количество записей возвращённых в клиентский record set , если в процессе работы не удалось получить требуемую информацию, значение второго параметра необходимо установить в -1, как признак неуспешного завершения.
.
А вот шаблон расширенной хранимой процедуры, который нам предстоит наполнить содержанием:
Работа с входными параметрами
В этой главе я не хочу рассеивать Ваше внимание на посторонних вещах, а хочу сосредоточить его на работе с переданными в расширенную хранимую процедуру параметрами. Поэтуму мы несколько упростим наше техническое задание и разработаем тольку ту его часть, которая работает с входными параметрами. Но сначал не много теории
Первое действие, которое должна выполнить наша exteneded stored procedure , - получить параметры, которые были переданы ей при вызове. Следуя приведённому выше алгоритму нам необходимо выполнить следующие действия:
- Определить кол-во переданных параметров;
- Убедится, что переданные параметры имеют верный тип данных;
- Убедиться, что указанный OUTPUT параметр имеет достаточную длину, для сохранения в нём значения возвращаемого нашей extended stored procedure.
- Получить переданные параметры;
- Установить значения выходного параметра как результат успешного/неуспешного завершения работы extended stored procedure .
Теперь рассмотрим подробно каждый пункт:
Определение количества переданных в расширенную хранимую процедуру параметров
Для получения количества переданных параметров необходимо использовать функцию:
.
При успешном завершении функция возвращает количество переданных в расширенную хранимую процедуру параметров. Если extended stored procedure была вызвана без параметров - srv_rpcparams ввернёт -1. Параметры могут быть переданы по имени или по позиции (unnamed). В любом случае, нельзя смешивать эти два способа. Попытка передачи в функцию входных параметров по имени и по позиции одновременно - приведёт к возникновению ошибки, и srv_rpcparams вернёт 0 .
[pagebreak]
Определение типа данных и длины переданых параметров
Для получения информации о типе и длине переданных параметров Microsoft рекомендует использовать функцию srv_paramifo. Эта универсальная функция заменяет вызовы srv_paramtype, srv_paramlen, srv_parammaxlen, которые теперь считаются устаревшими. Вот её прототип:
.
.
.
.
.
.
.
.
.
.
pByte - указатель на переменную получающую информацию о типе входного параметра;
pbType задаёт порядковый номер параметра. Номер первого параметра начинается с 1.
pcbMaxLen - указатель на переменную, в которую функция заносит максимальное значение длины параметра. Это значение обусловлено конкретным типом данных переданного параметра, его мы и будем использовать, чтобы убедиться втом, что OUTPUT параметр имеет достаточную длину для сохранения передаваемых данных.
pcbActualLen указатель на реальную длину параметра переданного в расширенную хранимую процедуру при вызове. Если передаваемый параметр имеет нулевую длину, а флаг pfNull устанавлен в FALSE то (* pcbActualLen) ==0.
pbData - указатель на буфер, память для которого должна быть выделена перед вызовом srv_paraminfo. В этом буфере функция размещает полученные от extended stored procedure входные параметры. Размер буфера в байтах равен значению pcbMaxLen. Если этот параметр установлен в NULL, данные в буфер не записываются, но функция корректно возвращает значения *pbType, *pcbMaxLen, *pcbActualLen, *pfNull. Поэтому вызывать srv_paraminfo нужно дважды: сначала с pbData=NULL, потом, выделив необходимый размер памяти под буфер равный pcbActualLen, вызвать srv_paraminfo второй раз, передав в pbData указатель на выделенный блок памяти.
pfNull указатель на NULL-флаг. srv_paraminfo устанавливает его в TRUE, если значение входного параметра равно NULL.
Проверка, является ли второй параметр OUTPUT параметром.
Функция srv_paramstatus() предназначена для определения статуса переданного параметра:
.
.
.
.
.
n - номер параметра переданного в расширенную хранимую процедуру при вызове. Напомню: параметры всегда нумеруются с 1.
Для возврата значения, srv_paramstatus использует нулевой бит. Если он установлен в 1 переданный параметр является OUTPUT параметром, если в 0 обычным параметром, переданным по значению. Если, exteneded stored procedure была вызвана без параметров, функция вернёт -1.
Установка значения выходного параметра.
Выходному параметру, переданному в расширеную хранимую можно передать значение используя функцию srv_paramsetoutput. Эта новая функция заменяет вызов функции srv_paramset, которая теперь считается устаревашай, т.к. не поддерживает новые типы данных введённые в ODS API и данные нулевой длины.
.
.
.
.
.
.
.
.
n - порядковый номер параметра, которому будет присвоено новое значение. Это должен быть OUTPUT параметр.
pbData указатель на буфер с данными, которые будут посланы клиенту для установки значения выходного параметра.
cbLen длина буфера посылаемых данных. Если тип данных переданного OUTPUT параметра определяет данные постоянной длины и не разрешает хранение значения NULL (например SRVBIT или SRVINT1), то функция игнорирует параметр cbLen. Значение cbLen=0 указывает на данные нулевой длины, при этом парметр fNull должен быть установлен в FALSE.
fNull установите этот его в TRUE, если возвращаемому параметру необходимо присвоить значение NULL, при этом значение cbLen должно быть равно 0, иначе функция завершится с ошибкой. Во всех остальных случаях fNull=FALSE.
В случае успешного завершения функция возвращает SUCCEED. Если возвращаемое значение равно FAIL, значит вызов был неудачным. Всё просто и понятно
Теперь мы достаточно знаем, для того чтобы написать свою первую расширенную хранимую процедуру, которая будет возвращать значение через переданный ей параметр.Пусть, по сложившейся традиции, это будет строка Hello world! Отладочну версию примера можно скачать здесь.
. Не рассмотренными остались функции srv_sendmsg и srv_senddone. Функция srv_sendmsg используется для посылки сообщений клиенту. Вот её прототип:
msgtype определяет тип посылаемого клиенту сообщения. Константа SRV_MSG_INFO обозначает информационное сообщение, а SRV_MSG_ERROR сообщение об ошибке;
msgnum номер сообщения;
class - степень тяжести возникшей ошибки. Информационные сообщения имеют значение степени тяжести меньшее или равное 10;
state номер состояния ошибки для текущего сообщения. Этот параметр предоставляет информацию о контексте возникшей ошибки. Допустимые значения лежат в диапазоне от 0 до 127;
rpcname в настоящее время не используется;
rpcnamelen - в настоящее время не используется;
linenum здесь можно указать номер строки исходного кода. По этому значению, в последствие будет легко установить в каком месте возникла ошибка. Если Вы не хотите использовать эту возможность, тогда установите linenum в 0;
message указатель на строку посылаемую клиенту;
msglen определяет длину в байтах строки сообщения. Если это строка заканчивается нулевым символом, то значение этого параметра можно установить равным SRV_NULLTERM.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
В процессе работы расширенная хранимая процедура должна регулярно сообщать клиентскому приложению свой статус, т.е. посылать сообщения о выполненных действиях. Для этого и предназначена функция srv_senddone:
status - статус флаг. Значение этого параметра можно задавать использую логические операторы AND и OR для комбинирования констант приведённых в таблице:
Status flag Описание
SRV_DONE_FINAL Текущий набор результатов является окончательным;
SRV_DONE_MORE Текущий набор результатов не является окончательным следует ожидать очердную порцию данных;
SRV_DONE_COUNT Параметр count содержит верное значение
SRV_DONE_ERROR Используется для уведомления о возникновении ошибок и немедленном завершении.
into зарезервирован, необходимо установить в 0.
count количество результирующих наборов данных посылаемых клиенту. Если флаг status установлен в SRV_DONE_COUNT, то count должен содержать правильное количество посылаемый клиенту наборв записей.
Возвращаемыме значения:
- в случае успеха SUCCEED
- при неудаче FAIL.
Установка расширенных хранимых процедур на MS SQL Server 2000
1.Скопируйте dll библиотеку с расширенной хранимой процедурой в каталог binn на машине с установленным MS SQL Server. У меня этот путь следующий: C:Program FilesMicrosoft SQL ServerMSSQLBinn;
2.Зарегистрирйте расширенную хранимую процедуру на серверt выполнив следующий скрипт:
Заключение
На этом первая часть моей статьи закончена. Теперь я уверен Вы готовы справиться с нашим техническим заданием на все 100%. В следующей статье Вы узнаете:
- Типы данных определённые в ODS API;
- Особенности отладки расширенных хранимых процдур;
- Как формировать recordset-ы и передавать их клиентскому приложению;
- Чстично мы рассмотрим функции Active Directory Network Manegment API необходимые для получения списка доменных пользователей;
- Создадим готовый проект (реализуем наше техническое задание)
Надеюсь - до скорой встречи!
Реферал - это url, с которого посетитель приходит на ваш сайт. К примеру, на странице http://www.site.com/links.html есть ссылка на ваш сайт. Если человек нажмет на нее, то он попадет на ваш сайт. Тогда url http://www.site.com/links.html будет вашим рефералом. Каждому владельцу ресурса не будет лишним знать, откуда именно заходят посетители на его сайт. Для тех, кому интересно решение данной проблемы (задачи) с помощью PHP, и посвящена данная статья.
Не спорю, что у любой уважающей себя CMS (content management system, система управления содержанием) есть модули (боты), которые отвечают за сбор статистики. Для тех же, у кого на сайте не стоит CMS, есть возможность попрактиковаться в написании и конфигурировании собственного мини-модуля статистики.
Его можно реализовать в небольшом скрипте, который будет отслеживать нажатия на ссылки, записывать их URL'ы в базу данных (в нашем примере это MySQL) и генерировать статистику в виде графика. Да и поможет разобраться, как это все работает на самом деле, не копаясь в модулях сторонних разработчиков.
Нам потребуется три файла:
* referer.sql (запрос к БД на создание таблицы, где будет храниться статистика);
* referer.php (сам скрипт);
* viewreferer.php (скрипт для просмотра статистики).
Для создания таблицы referer необходимо выполнить запрос referer.sql. Вот его содержание:
Теперь займемся файлом referer.php. Зададим значения переменным:
.
.
.
.
.
.
.
.
.
.
.
.
В переменную $ref заносим информацию о ссылке-реферере:
.
.
С помощью функции strtolower переводим значение переменной $ref в нижний регистр. Это делается для того, чтобы ссылки типа www.site.com, www.Site.com или WWW.SITE.COM были одинакового регистра.
Если переменная $ref не пустая,
.
.
то подключаемся к БД:
Производим выборку из столбца url, значение которого совпадает с $ref
Переменная $rows содержит количество совпадений
.
.
.
Если же не найдено ни одной записи (т.е c такого url'a еще не было рефералов)
устанавливаем значение переменной $hits в "1"
.
.
А далее просто выполняем вставку url'а и переменной $hits в нашу таблицу (referer):
Выполняем запрос:
.
.
.
Если же были найдены записи по данному url (т.е c этого url'a уже заходили рефералы),
Инкрементируем значение переменной $hits (увеличиваем на "1")
.
.
.
.
.
.
В ту страницу сайта, для которой необходима статистика по рефералам (как правило - это главная страница, index.php), необходимо вставить ссылку на скрипт referer.php. Предполагается, что файлы referer.php и index.php находятся в одной папке.
.
.
.
На этом и заканчивается содержимое скрипта referer.php. Но, как я написал выше, есть также и графическая статистика. Это будет наш третий файл - viewreferer.php.
Задаем переменные для подключения к БД:
.
.
.
.
.
.
Так как этот скрипт генерирует таблицу с графиком, то есть смысл для определенных диапазонов значений хитов назначить определенные цвета.
Опять соединяемся с БД:
Делаем выборку из БД и упорядочиваем ее по убыванию (desc) количества хитов (столбец hits).
Подсчитываем количество строк с уникальными рефералами (это попросту число строк в нашей таблице referer).
.
.
.
Если же не найдено ни одной записи (таблица пуста), то выводим сообщение:
Выбираем цвет для текущего значения hits:
Табличка с графиком строится как результат MySQL-запроса. В первой колонке содержится название url'а, а во второй - количество хитов, а в третей - цветная полоса.
.
.
.
.
.
.
.
.
.
.
.
Итак, все готово! Теперь можно периодически вызывать скрипт viewreferer.php и смотреть графическую статистику переходов на ваш сайт.