В те дни, когда душа моя страдала от отсутствия триггеров в Access, на sql.ru их взяли и сделали через constraints: http://www.sql.ru/forum/actualthread.aspx?bid=4&tid=545973&pg=-1#5530877. Если в примере разобраться, то всё очень просто.
Поиск до сих пор не выдаёт эту тему в первой 20-ке, поэтому считаю должным об этом сказать. Может быть, хоть кто-то наткнётся на этот островок в море заявлений "написать триггер в MDB невозможно". Возможно!
Хотя, конечно, это не полноценный триггер. Мне не удалось повесить его на таблицу с пробелом в названии... Человек, который писал нашу базу, в момент её создания не был программистом, к сожалению. :)
среда, 10 июня 2009 г.
Ускорение связки SQL - MDB (Jet 4.0)
В связке Windows Server 2003 - MSSQL 2000 есть одна настройка в виде "галочки". По умолчанию она выключена. Если её включить, то скорость доступа SQL к файлу .MDB на локальном диске повышается в несколько раз. Я открываю простые запросы через Jet 4.0.
Я нашёл эту настройку год назад и очень обрадовался. Я тогда делал обновление между базами Access и SQL, не зная, что в Access 97 можно сделать триггер. Теперь захотел ещё раз её найти (после наката SP2 на Windows Server стали происходить необъяснимые вещи). Долго искал и не нашёл. Ни в интернете, ни в каких настройках.
Из-за этого вчера даже зарегистрировался на этом сайте. Всё-таки в профессиональных целях интернет может быть очень полезным.
Я нашёл эту настройку год назад и очень обрадовался. Я тогда делал обновление между базами Access и SQL, не зная, что в Access 97 можно сделать триггер. Теперь захотел ещё раз её найти (после наката SP2 на Windows Server стали происходить необъяснимые вещи). Долго искал и не нашёл. Ни в интернете, ни в каких настройках.
Из-за этого вчера даже зарегистрировался на этом сайте. Всё-таки в профессиональных целях интернет может быть очень полезным.
вторник, 9 июня 2009 г.
Access 97: в запросе не работают функции
Ну не работают функции в запросе: Mid, Left, Right, Format. Описание ошибки не поддаётся никакому описанию, просто бред какой-то. Они ему посвятили целый KB! И я здесь напишу, т.к. этот KB я нашёл с огромным трудом.
Итак: в редакторе VBA заходим в Tools - References (Сервис - Ссылки). Выбираем любой компонент, который нам совершенно не нужен и потому не отмечен. Отмечаем его! Нажимаем ОК. Снова открываем это окошко. Убираем галочку напротив этого компонента. Убираем-убираем, так надо! Нажимаем ОК. Всё! Какие-то там ссылки обновились... Mid работает!
Итак: в редакторе VBA заходим в Tools - References (Сервис - Ссылки). Выбираем любой компонент, который нам совершенно не нужен и потому не отмечен. Отмечаем его! Нажимаем ОК. Снова открываем это окошко. Убираем галочку напротив этого компонента. Убираем-убираем, так надо! Нажимаем ОК. Всё! Какие-то там ссылки обновились... Mid работает!
Зачем нужна .NET Runtime Optimization Service v2.0.50727_X86, и как извлечь из неё пользу
Службы, содержащие в названии подстроку .NET и запущенные всё время, обычно вызывают большое желание отключить их. Так было и с .NET Runtime Optimization Service v2.0.50727_X86, съедающей несколько казённых мегабайт. Хотя я как будто бы специально не использую .NET, она всё-таки нужна.
Как известно, традиционное приложение на .NET не является Windows-приложением. Оно содержит некий кросс-платформенный код, который на конкретной машине Windows преобразуется в native code для Windows. Это называется just-in-time, или JIT-компиляцией. Процессор выполняет native code.
В этой схеме есть огромные плюсы для девелопера, но для рутинной юзерской работы чистый JIT был бы кошмаром. Поэтому против JIT создали естественное противоядие: пре-компиляция, pre-JIT. Служба .NET Runtime Optimization Service в фоновом режиме компилирует все имеющиеся сборки .NET в "родной" код Windows и складывает их в некий кэш. И в дальнейшем, при обновлении частей кода .NET, по необходимости повторяет пре-компиляцию. Вот в чём разгадка долгих тормозов компьютера с недавно установленным или обновлённым .NET!
Что же здесь можно сделать полезного?
Вполне естественно желание перенести все эти тормоза с рабочего времени на время обеда. И оно осуществимо! Мы можем вручную выполнить весь pre-JIT, ожидающий своей очереди, чтобы впоследствии избежать всех возможных тормозов.
Смотрим, откуда запускается эта служба. У меня, например, из папки:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
Из этой папки выполняем команду ngen.exe executequeueditems. У меня она выполнялась, наверно, полчаса. После этого запустим её ещё раз и порадуемся сообщению: All compilation targets are up to date.
См. также статью в David Notario's WebLog.
Как известно, традиционное приложение на .NET не является Windows-приложением. Оно содержит некий кросс-платформенный код, который на конкретной машине Windows преобразуется в native code для Windows. Это называется just-in-time, или JIT-компиляцией. Процессор выполняет native code.
В этой схеме есть огромные плюсы для девелопера, но для рутинной юзерской работы чистый JIT был бы кошмаром. Поэтому против JIT создали естественное противоядие: пре-компиляция, pre-JIT. Служба .NET Runtime Optimization Service в фоновом режиме компилирует все имеющиеся сборки .NET в "родной" код Windows и складывает их в некий кэш. И в дальнейшем, при обновлении частей кода .NET, по необходимости повторяет пре-компиляцию. Вот в чём разгадка долгих тормозов компьютера с недавно установленным или обновлённым .NET!
Что же здесь можно сделать полезного?
Вполне естественно желание перенести все эти тормоза с рабочего времени на время обеда. И оно осуществимо! Мы можем вручную выполнить весь pre-JIT, ожидающий своей очереди, чтобы впоследствии избежать всех возможных тормозов.
Смотрим, откуда запускается эта служба. У меня, например, из папки:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727
Из этой папки выполняем команду ngen.exe executequeueditems. У меня она выполнялась, наверно, полчаса. После этого запустим её ещё раз и порадуемся сообщению: All compilation targets are up to date.
См. также статью в David Notario's WebLog.
Access не открывает два файла MDB одновременно
Если Access не может открыть одновременно две базы, то это похоже на проблему с доступом на запись к папке WINDOWS\SYSTEM32.
1. Копируем файл system.mdw из папки SYSTEM32 туда, где у нас есть все права (например, D:\SYSTEM\system.mdw).
2. Запускаем WINDOWS\SYSTEM32\wrkgadm.exe, нажимаем Связь... и указываем наш новый путь к system.mdw.
1. Копируем файл system.mdw из папки SYSTEM32 туда, где у нас есть все права (например, D:\SYSTEM\system.mdw).
2. Запускаем WINDOWS\SYSTEM32\wrkgadm.exe, нажимаем Связь... и указываем наш новый путь к system.mdw.
Запуск задачи с правами SYSTEM
Бывает, что нужны права побольше, чем у локального админа. Например, когда хочется удалить Касперского, который удалённо ставился админами домена.
Да, оказывается, есть такой локальный пользователь, права которого в чём-то превосходят права любого локального администратора. Это пользователь SYSTEM. Под ним, как правило, запускаются службы. Есть замечательная софтина AppToService, которая практически любое приложение сделает системной службой. Я много использую Total Commander, поэтому его я и сделал службой. А всё, что будет запущено из его командной строки, также пойдёт с правами SYSTEM.
Кстати, насчёт командной строки: команды для Windows XP.
Да, оказывается, есть такой локальный пользователь, права которого в чём-то превосходят права любого локального администратора. Это пользователь SYSTEM. Под ним, как правило, запускаются службы. Есть замечательная софтина AppToService, которая практически любое приложение сделает системной службой. Я много использую Total Commander, поэтому его я и сделал службой. А всё, что будет запущено из его командной строки, также пойдёт с правами SYSTEM.
Кстати, насчёт командной строки: команды для Windows XP.
Как удалить службу в Windows
Как удалить ненужную службу?
1. Узнаём её имя. То имя, под которым она выводится в списке служб - это не то! Нам надо в свойствах службы найти первую строчку: "Имя службы".
2. В командной строке набираем: sc delete "Имя службы" (кавычки обязательны, если в имени службы есть пробелы).
Удалится всё, что угодно. Если не разрешит, то проверяем, являемся ли мы локальным админом. Если да, то юзаем незаменимый AppToService.
1. Узнаём её имя. То имя, под которым она выводится в списке служб - это не то! Нам надо в свойствах службы найти первую строчку: "Имя службы".
2. В командной строке набираем: sc delete "Имя службы" (кавычки обязательны, если в имени службы есть пробелы).
Удалится всё, что угодно. Если не разрешит, то проверяем, являемся ли мы локальным админом. Если да, то юзаем незаменимый AppToService.
Подписаться на:
Сообщения (Atom)