Odd item in MySql error log
MySql 5.0.41 SUSE 10.2 Linux dbms-04-r1 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux Dear MySql, I have an odd item in my error log, I wonder if you can tell me what this means? Also whether should do anything about it? (This table once corrupted before, I could not start MySql, and had several hours downtime recovering it...) 071219 0:00:15 InnoDB: Error: trying to declare trx to enter InnoDB, but InnoDB: it already is declared. TRANSACTION 0 3825296174, ACTIVE 0 sec, process no 6929, OS thread id 1141946688, thread declared inside InnoDB 0 mysql tables in use 1, locked 1 1 lock struct(s), heap size 368 MySQL thread id 16, query id 158 fls-16-03.roadtech.private 172.16.14.12 sdi update INSERT INTO terminal_log (mem_code, terminal_id, last_call, latitude, longitude, speed_knots, course, cablink_string, ip_addr, temperature) VALUES ( NULL , '35126600409511509' , '2007-12-18 23:59:58' , '5.150556400501e+01' , '-3.696216681689e-01' , '8.00016653e-02' , '1.0 Many thanks! Ben Clewett. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Mysql and Perl
On Monday 25 September 2006 20:09, George Law wrote: damn outlook! fire up perl's CPAN interface: perl -MCPAN -eshell cpan i /mysql/ ... Bundle Bundle::DBD::mysql (C/CA/CAPTTOFU/DBD-mysql-3.0007.tar.gz) ... cpan install Bundle::DBD::mysql Hello again... I'm back to this problem I had over a year ago. Yesterday I had to reinstall my system, since the disk containint the OS crashed. After a few hours I was back in businness again - except for the Perl module. My perl scripts does not work anymore. I have tried to install the Bundle::DBD::mysql, but it failes with the same error I had last time (see below). Somehow I managed to fix this the last time, but I forgot to write down what I did (shame on me). So... is there any kind soul out there that can give me some hints about how to fix this problem? Output when installing the bundle: -- cpan install Bundle::DBD::mysql DBI is up to date. Data::ShowTable is up to date. Running install for module Mysql Running make for R/RU/RUDY/DBD-mysql-2.9008.tar.gz CPAN: Digest::MD5 loaded ok CPAN: Compress::Zlib loaded ok Checksum for /root/.cpan/sources/authors/id/R/RU/RUDY/DBD-mysql-2.9008.tar.gz ok Scanning cache /root/.cpan/build for sizes DBD-mysql-2.9008/ DBD-mysql-2.9008/t/ DBD-mysql-2.9008/t/60leaks.t DBD-mysql-2.9008/t/40listfields.t DBD-mysql-2.9008/t/10dsnlist.t DBD-mysql-2.9008/t/40numrows.t DBD-mysql-2.9008/t/30insertfetch.t DBD-mysql-2.9008/t/00base.t DBD-mysql-2.9008/t/insertid.t DBD-mysql-2.9008/t/50commit.t DBD-mysql-2.9008/t/40nulls.t DBD-mysql-2.9008/t/dbdadmin.t DBD-mysql-2.9008/t/lib.pl DBD-mysql-2.9008/t/20createdrop.t DBD-mysql-2.9008/t/mysql.dbtest DBD-mysql-2.9008/t/40bindparam.t DBD-mysql-2.9008/t/mysql.t DBD-mysql-2.9008/t/40blobs.t DBD-mysql-2.9008/t/akmisc.t DBD-mysql-2.9008/t/50chopblanks.t DBD-mysql-2.9008/t/ak-dbd.t DBD-mysql-2.9008/t/mysql2.t DBD-mysql-2.9008/lib/ DBD-mysql-2.9008/lib/DBD/ DBD-mysql-2.9008/lib/DBD/mysql/ DBD-mysql-2.9008/lib/DBD/mysql/GetInfo.pm DBD-mysql-2.9008/lib/DBD/mysql/INSTALL.pod DBD-mysql-2.9008/lib/DBD/mysql.pm DBD-mysql-2.9008/lib/Bundle/ DBD-mysql-2.9008/lib/Bundle/DBD/ DBD-mysql-2.9008/lib/Bundle/DBD/mysql.pm DBD-mysql-2.9008/lib/Mysql/ DBD-mysql-2.9008/lib/Mysql/Statement.pm DBD-mysql-2.9008/lib/Mysql.pm DBD-mysql-2.9008/TODO DBD-mysql-2.9008/myld DBD-mysql-2.9008/constants.h DBD-mysql-2.9008/dbdimp.c DBD-mysql-2.9008/dbdimp.h DBD-mysql-2.9008/README DBD-mysql-2.9008/MANIFEST.SKIP DBD-mysql-2.9008/Makefile.PL DBD-mysql-2.9008/META.yml DBD-mysql-2.9008/INSTALL.html DBD-mysql-2.9008/ChangeLog DBD-mysql-2.9008/MANIFEST DBD-mysql-2.9008/mysql.xs Removing previously used /root/.cpan/build/DBD-mysql-2.9008 CPAN.pm: Going to build R/RU/RUDY/DBD-mysql-2.9008.tar.gz I will use the following settings for compiling and testing: cflags(mysql_config) = -I/usr/include/mysql -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing libs (mysql_config) = -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib -lssl -lcrypto mysql_config (guessed ) = mysql_config nocatchstderr (default ) = 0 nofoundrows (default ) = 0 ssl (guessed ) = 1 testdb(default ) = test testhost (default ) = testpassword (default ) = testsocket(default ) = testuser (default ) = To change these settings, see 'perl Makefile.PL --help' and 'perldoc INSTALL'. Checking if your kit is complete... Looks good Using DBI 1.48 (for perl 5.008006 on x86_64-linux-thread-multi) installed in /usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/auto/DBI/ Writing Makefile for DBD::mysql cp lib/DBD/mysql.pm blib/lib/DBD/mysql.pm cp lib/DBD/mysql/GetInfo.pm blib/lib/DBD/mysql/GetInfo.pm cp lib/Mysql.pm blib/lib/Mysql.pm cp lib/DBD/mysql/INSTALL.pod blib/lib/DBD/mysql/INSTALL.pod cp lib/Mysql/Statement.pm blib/lib/Mysql/Statement.pm cp lib/Bundle/DBD/mysql.pm blib/lib/Bundle/DBD/mysql.pm gcc -c -I/usr/lib64/perl5/vendor_perl/5.8.6/x86_64-linux-thread-multi/auto/DBI/ -I/usr/include/mysql -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32 -march=i386 -mtune=pentium4 -fasynchronous-unwind-tables -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-strict-aliasing -DDBD_MYSQL_WITH_SSL -DDBD_MYSQL_INSERT_ID_IS_GOOD -g -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -DVERSION=\2.9008\ -DXS_VERSION=\2.9008\ -fPIC -I/usr/lib64/perl5/5.8.6/x86_64-linux-thread-multi/CORE dbdimp.c dbdimp.c:1: error: CPU you selected does not support x86-64 instruction set make: *** [dbdimp.o] Error 1 /usr/bin/make -- NOT OK Running make test Can't
Applying LIMIT to SELECT count(*)
Hi, My task is to limit calculation of total number of items in the database that satisfy certain conditions. I join two tables using WHERE and there are millions of records as the result. When I do SELECT count(*) it takes really too long. The table has appropriate indexes and I experimented with replacing the conditions, etc., so I don't think there is a way to make it work any faster. In my case it would be anough to say that there are more than e.g. 50 000 of items instead of calculating the exact quantity. My question is how to apply a certain limit to count() function in order it would either return the real quantity if it is smaller than the limit or return the limit and stop further calculation, quite same as when using SELECT * FROM ... LIMIT 0, 100 Another option could be estimating approximate quantity in the result but it seems to me much more complex and I honestly don't know where to start from. Thanks! -- View this message in context: http://www.nabble.com/Applying-LIMIT-to-SELECT-count%28*%29-tp14453544p14453544.html Sent from the MySQL - General mailing list archive at Nabble.com. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
regarding outfile
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Odd item in MySql error log
Good Morning Ben this is an acknowledged bug http://bugs.mysql.com/bug.php?id=20090 which was fixed in 5.1.22-beta + can you upgrade? Martin-- - Original Message - From: Ben Clewett [EMAIL PROTECTED] To: mysql@lists.mysql.com Sent: Friday, December 21, 2007 4:52 AM Subject: Odd item in MySql error log MySql 5.0.41 SUSE 10.2 Linux dbms-04-r1 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux Dear MySql, I have an odd item in my error log, I wonder if you can tell me what this means? Also whether should do anything about it? (This table once corrupted before, I could not start MySql, and had several hours downtime recovering it...) 071219 0:00:15 InnoDB: Error: trying to declare trx to enter InnoDB, but InnoDB: it already is declared. TRANSACTION 0 3825296174, ACTIVE 0 sec, process no 6929, OS thread id 1141946688, thread declared inside InnoDB 0 mysql tables in use 1, locked 1 1 lock struct(s), heap size 368 MySQL thread id 16, query id 158 fls-16-03.roadtech.private 172.16.14.12 sdi update INSERT INTO terminal_log (mem_code, terminal_id, last_call, latitude, longitude, speed_knots, course, cablink_string, ip_addr, temperature) VALUES ( NULL , '35126600409511509' , '2007-12-18 23:59:58' , '5.150556400501e+01' , '-3.696216681689e-01' , '8.00016653e-02' , '1.0 Many thanks! Ben Clewett. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Can anybody know how to determinate whether a variable 's type?
On Dec 21, 2007 7:45 PM, Moon's Father [EMAIL PROTECTED] wrote: If you know ,just tell me,thanks. etc. declare cnt int default 0; How can I know what type the variabe cnt is? Can't 'desc table' show what you want? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Finding the 'nearest' text match
I have two datasets that I wish to relate together using the company name. The problem is the same company may have a slightly different name in each the two datasets. What I want to do is for each company name in dataset A, find the 'nearest' n matches to it in dataset B. e.g. If I have 'Alkool Inc.', the nearest matches could be: Alcool Alcool inc AlKool Partners KB Alkoool Akool Ltd. etc I've looked into SOUNDEX but this doesn't work as the initial letters may be different. A variation of SOUNDEX could work if it always returned n 'closest' matches though Is such a thing possible? MySQL full-text searching is out as I'm using InnoDB tables. Does anyone have any suggestions? Thanks! Edward -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
MySQL5.1 estimated release date?
Hi, A silly question. Is there anybody knowing estimated GA release date for MySQL 5.1? I heard it was planed to be released in december this year and the latest release 5.1.22 is RC, but seems that it will not happen soon. Thanks. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
cache in mysql Windows
Hello We are doing some performance tests and would like to disable the cache. We did set the query_cache_size=0 but it did not have any effect as well as a select no_cache. The process is a select on MyISAM table. We are using a Mysql 5.0.27. We are wondering if Mysql uses a file to cache or something like this. The first request take several seconds but the second is instantaneous. Even if we stop Mysql it does the second one very fast. It is quite odd. Any clue? Thank you for your help Johanne
Re: cache in mysql Windows
At 9:01 AM -0500 12/21/07, Duhaime Johanne wrote: Hello We are doing some performance tests and would like to disable the cache. We did set the query_cache_size=0 but it did not have any effect as well as a select no_cache. The process is a select on MyISAM table. We are using a Mysql 5.0.27. We are wondering if Mysql uses a file to cache or something like this. The first request take several seconds but the second is instantaneous. Even if we stop Mysql it does the second one very fast. It is quite odd. Any clue? You might be seeing the effect of filesystem caching even when the MySQL query cache is disabled. -- Paul DuBois, MySQL Documentation Team Madison, Wisconsin, USA MySQL AB, www.mysql.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Applying LIMIT to SELECT count(*)
If exact number isn't important, you might want to try table_rows in information_schema.tables or show table status. On Dec 21, 2007 7:53 PM, Urms [EMAIL PROTECTED] wrote: Hi, My task is to limit calculation of total number of items in the database that satisfy certain conditions. I join two tables using WHERE and there are millions of records as the result. When I do SELECT count(*) it takes really too long. The table has appropriate indexes and I experimented with replacing the conditions, etc., so I don't think there is a way to make it work any faster. In my case it would be anough to say that there are more than e.g. 50 000 of items instead of calculating the exact quantity. My question is how to apply a certain limit to count() function in order it would either return the real quantity if it is smaller than the limit or return the limit and stop further calculation, quite same as when using SELECT * FROM ... LIMIT 0, 100 Another option could be estimating approximate quantity in the result but it seems to me much more complex and I honestly don't know where to start from. Thanks! -- View this message in context: http://www.nabble.com/Applying-LIMIT-to-SELECT-count%28*%29-tp14453544p14453544.html Sent from the MySQL - General mailing list archive at Nabble.com. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Applying LIMIT to SELECT count(*)
The problem is that there are certain conditions after WHERE different for each query and the results number can be very different. -- View this message in context: http://www.nabble.com/Applying-LIMIT-to-SELECT-count%28*%29-tp14453544p14459808.html Sent from the MySQL - General mailing list archive at Nabble.com. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Applying LIMIT to SELECT count(*)
Oh, I misunderstood,sorry. Using summary tables doesn't work for you? On Dec 22, 2007 3:00 AM, Urms [EMAIL PROTECTED] wrote: The problem is that there are certain conditions after WHERE different for each query and the results number can be very different. -- View this message in context: http://www.nabble.com/Applying-LIMIT-to-SELECT-count%28*%29-tp14453544p14459808.html Sent from the MySQL - General mailing list archive at Nabble.com. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED] -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
DB acts like a good db but is really corrupt?
I have one table in my database that is completely unhappy with mysqldump. However, it acts like it's just fine. Performing checks on this table comes up okay: mysql CHECK TABLE post; ++---+--+--+ | Table | Op| Msg_type | Msg_text | ++---+--+--+ | forum_new.post | check | status | OK | ++---+--+--+ 1 row in set (1 min 8.13 sec) myisamchk is also happy with it: myisamchk -c post Checking MyISAM file: post Data records: 2012438 Deleted blocks: 0 - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 - check data record references index: 2 - check data record references index: 3 - check data record references index: 4 - check data record references index: 5 - check data record references index: 6 - check data record references index: 7 - check data record references index: 8 - check record links The more extensive check even comes up okay: myisamchk -m post Checking MyISAM file: post Data records: 2012438 Deleted blocks: 0 - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 - check data record references index: 2 - check data record references index: 3 - check data record references index: 4 - check data record references index: 5 - check data record references index: 6 - check data record references index: 7 - check data record references index: 8 - check record links But when I run mysqldump, I get this error: mysqldump -aA --opt -Q -u backup_user -p file.sql mysqldump: Got error: 1016: Can't open file: 'post.MYI' (errno: 144) when using LOCK TABLES And when I make sure that we don't use locks, it still doesn't work: mysqldump -A --skip-opt -u backup_user -p post.sql mysqldump: mysqldump: Couldn't execute 'show create table `post`': Can't open file: 'post.MYI' (errno: 144) (1016) However, everything is running fine with this database. I can select from it, insert stuff into it, etc, with absolutely no problems at all. Repeated repairs have done nothing. At one point, I even copied everything out of this table into a new table (via INSERT INTO new_table SELECT * FROM oldtable), and dropped the old table, and I get the exact same error message. I am running 4.1.11 on Debian Sarge. Since I can't get a backup of this (critical) data, I'm loathe to do anything too risky. Any thoughts or suggestions would be greatly appreciated. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: Hi,I want to know how big to configurate the max-connections parameter in my.cnf?
On Dec 22, 2007 10:55 AM, Moon's Father [EMAIL PROTECTED] wrote: how big your mysql connections's users. How big users? don't know what you said. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: DB acts like a good db but is really corrupt?
Hi, On Dec 21, 2007 8:08 PM, cirisme [EMAIL PROTECTED] wrote: I have one table in my database that is completely unhappy with mysqldump. However, it acts like it's just fine. Performing checks on this table comes up okay: mysql CHECK TABLE post; ++---+--+--+ | Table | Op| Msg_type | Msg_text | ++---+--+--+ | forum_new.post | check | status | OK | ++---+--+--+ 1 row in set (1 min 8.13 sec) myisamchk is also happy with it: myisamchk -c post Checking MyISAM file: post Data records: 2012438 Deleted blocks: 0 - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 - check data record references index: 2 - check data record references index: 3 - check data record references index: 4 - check data record references index: 5 - check data record references index: 6 - check data record references index: 7 - check data record references index: 8 - check record links The more extensive check even comes up okay: myisamchk -m post Checking MyISAM file: post Data records: 2012438 Deleted blocks: 0 - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 - check data record references index: 2 - check data record references index: 3 - check data record references index: 4 - check data record references index: 5 - check data record references index: 6 - check data record references index: 7 - check data record references index: 8 - check record links But when I run mysqldump, I get this error: mysqldump -aA --opt -Q -u backup_user -p file.sql mysqldump: Got error: 1016: Can't open file: 'post.MYI' (errno: 144) when using LOCK TABLES And when I make sure that we don't use locks, it still doesn't work: mysqldump -A --skip-opt -u backup_user -p post.sql mysqldump: mysqldump: Couldn't execute 'show create table `post`': Can't open file: 'post.MYI' (errno: 144) (1016) However, everything is running fine with this database. I can select from it, insert stuff into it, etc, with absolutely no problems at all. Repeated repairs have done nothing. At one point, I even copied everything out of this table into a new table (via INSERT INTO new_table SELECT * FROM oldtable), and dropped the old table, and I get the exact same error message. I am running 4.1.11 on Debian Sarge. Since I can't get a backup of this (critical) data, I'm loathe to do anything too risky. Any thoughts or suggestions would be greatly appreciated. Very odd. perror shows this: [EMAIL PROTECTED]:~$ perror 144 MySQL error code 144: Table is crashed and last repair failed Try to use SELECT INTO OUTFILE to get the data out. Is there anything odd about your setup, such as the data being on NFS? (just speculating). -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]
Re: DB acts like a good db but is really corrupt?
On Dec 21, 2007, at 9:15 PM, Baron Schwartz wrote: Hi, On Dec 21, 2007 8:08 PM, cirisme [EMAIL PROTECTED] wrote: I have one table in my database that is completely unhappy with mysqldump. However, it acts like it's just fine. Performing checks on this table comes up okay: mysql CHECK TABLE post; ++---+--+--+ | Table | Op| Msg_type | Msg_text | ++---+--+--+ | forum_new.post | check | status | OK | ++---+--+--+ 1 row in set (1 min 8.13 sec) myisamchk is also happy with it: myisamchk -c post Checking MyISAM file: post Data records: 2012438 Deleted blocks: 0 - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 - check data record references index: 2 - check data record references index: 3 - check data record references index: 4 - check data record references index: 5 - check data record references index: 6 - check data record references index: 7 - check data record references index: 8 - check record links The more extensive check even comes up okay: myisamchk -m post Checking MyISAM file: post Data records: 2012438 Deleted blocks: 0 - check file-size - check record delete-chain - check key delete-chain - check index reference - check data record references index: 1 - check data record references index: 2 - check data record references index: 3 - check data record references index: 4 - check data record references index: 5 - check data record references index: 6 - check data record references index: 7 - check data record references index: 8 - check record links But when I run mysqldump, I get this error: mysqldump -aA --opt -Q -u backup_user -p file.sql mysqldump: Got error: 1016: Can't open file: 'post.MYI' (errno: 144) when using LOCK TABLES And when I make sure that we don't use locks, it still doesn't work: mysqldump -A --skip-opt -u backup_user -p post.sql mysqldump: mysqldump: Couldn't execute 'show create table `post`': Can't open file: 'post.MYI' (errno: 144) (1016) However, everything is running fine with this database. I can select from it, insert stuff into it, etc, with absolutely no problems at all. Repeated repairs have done nothing. At one point, I even copied everything out of this table into a new table (via INSERT INTO new_table SELECT * FROM oldtable), and dropped the old table, and I get the exact same error message. I am running 4.1.11 on Debian Sarge. Since I can't get a backup of this (critical) data, I'm loathe to do anything too risky. Any thoughts or suggestions would be greatly appreciated. Very odd. perror shows this: [EMAIL PROTECTED]:~$ perror 144 MySQL error code 144: Table is crashed and last repair failed Try to use SELECT INTO OUTFILE to get the data out. Is there anything odd about your setup, such as the data being on NFS? (just speculating). No, nothing strange that I could possibly think of, certainly not on NFS. I will try the SELECT INTO OUTFILE soon, that is a very helpful suggestion. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]