1с mysql ошибка 1064
что это "синтаксис", о котором вы говорите? Это колдовство?
в то время как "синтаксис" - это слово, которое многие программисты сталкиваются в контексте компьютеры, по сути, заимствованы из более широкой лингвистики. Это относится к структуре предложения, т. е. правила грамматики; или, другими словами, правила, определяющие, что составляет действующий приговор в рамках языка.
например, следующее английское предложение содержит синтаксическую ошибку (поскольку неопределенная статья " a " всегда должна предшествовать существительному):
это предложение содержит синтаксическую ошибку a.
какое это имеет отношение к MySQL?
всякий раз, когда кто-то выдает команду компьютеру, одна из самых первых вещей, которые он должен сделать, это "разобрать" эту команду, чтобы понять ее. "Синтаксическая ошибка" означает, что синтаксический анализатор не может понять, что спрашивается, потому что он не представляет собой допустимую команду в языке: другими словами, команда нарушает грамматику программирования язык.
важно отметить, что компьютер должен понять команду, прежде чем он сможет что-либо с ней сделать. Поскольку есть синтаксическая ошибка, MySQL понятия не имеет, что нужно, и поэтому отказывается прежде чем он даже выглядит по базе данных и поэтому схема или содержимое таблицы не имеют значения.
очевидно, нужно определить, как это происходит, что команда нарушает грамматику MySQL. Это может показаться довольно непроницаемым, но MySQL очень старается помочь нам здесь. Все, что нам нужно сделать, это. --27-->
MySQL не только говорит нам ровно где синтаксический анализатор обнаружил ошибку синтаксиса, но также делает предложение для ее исправление. Например, рассмотрим следующую команду SQL:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE SET name='foo'' at line 1
MySQL говорит нам, что все казалось прекрасным до слова WHERE , но затем возникла проблема. Другими словами, он не ожидал встретить WHERE в этой точке.
подчиняться приказы!
MySQL также рекомендует, чтобы мы"проверьте руководство, которое соответствует нашей версии MySQL для правильного синтаксиса, чтобы использовать". Давайте сделаем это.
я используете MySQL версии 5.6, так что я буду говорить эта версия ручной ввод для UPDATE команда. Самое первое на странице-это грамматика команды (это верно для каждой команды):
в руководстве объясняется, как интерпретировать этот синтаксис в типографские и синтаксические соглашения, но для наших целей достаточно признать, что: предложения, содержащиеся в квадратных скобках [ и ] являются необязательными; вертикальные полосы | укажите альтернативы; и эллипсы . обозначьте либо опущение для краткости, либо то, что предыдущее предложение может быть повторено.
мы уже знаем, что парсер верил, что все в нашей команде было в порядке до WHERE ключевое слово, или другими словами До и включая ссылку на таблицу. Глядя на грамматику, мы видим, что table_reference должен следовать SET ключевое слово: тогда как в нашей команде за ним фактически следовали WHERE ключевое слово. Это объясняет, почему анализатор сообщает, что в этот момент возникла проблема.
примечание о бронировании
конечно, это был простой пример. Однако, следуя двум шагам, изложенным выше (т. е. наблюдая точно, где в команде парсер обнаружил, что грамматика была нарушена и сравнивается с описанием руководства что ожидалось в тот момент), практически каждая синтаксическая ошибка может быть легко идентифицирована.
я говорю "практически все", потому что есть небольшой класс проблем, которые не так легко обнаружить-и именно там парсер считает, что элемент языка, с которым столкнулся, означает одно, тогда как вы намереваетесь это означать другое. Возьмем следующий пример:
опять же, парсер не ожидает столкнуться WHERE в этот момент и так возникнет аналогичная синтаксическая ошибка-но вы не предназначались для этого where быть ключевым словом SQL: вы намеревались определить столбец для обновления! Однако, как указано в разделе Имена Объектов Схемы:
если идентификатор содержит специальные символы или является зарезервированным словом, вы должны цитировать всякий раз, когда вы обращаетесь к нему. (Исключение: зарезервированное слово, которое следует за точкой в полном имени, должно быть идентификатором, поэтому его не нужно цитировать.) Зарезервированные слова перечислены в раздел 9.3, "ключевые слова и зарезервированные слова".
символ цитаты идентификатора-это backtick (" ` "):
если ANSI_QUOTES включен режим SQL, также допустимо указывать идентификаторы в двойном предложении Маркс:
Если вы получаете ошибку с клиентом SQuirreL при запуске SQL rxpression с точкой с запятой, как процедура CREATE, то вам нужен плагин MySQL. Вы можете выбрать его при установке. По умолчанию он не выбран.
для моего случая я пытался выполнить код процедуры в MySQL, и из-за какой-то проблемы с сервером, на котором сервер не может понять, где закончить оператор, я получал код ошибки 1064. Поэтому я обернул процедуру пользовательским разделителем, и она работала нормально.
например, раньше было:
после установки разделителя это было так:
вы также получаете эту ошибку при попытке вставить JSON или другие данные со специальными символами, без необходимых кавычек, например:
различные причины.. скажем, например, если мы объявляем любую переменную, то она должна быть перед любым другим типом операторов. или нам нужно поставить блок BEGIN перед этим.
дает ошибку, поэтому нам нужно сделать это
это может быть потому, что ваша строка или вставленные данные содержат одиночная кавычка ' вы можете попробовать
функция для выхода из строки при вставке данных (insert query) в базу данных.
По крайней мере в 8.3 пишут что исправили)
Еще вариант сделать на проблемные таблицы вьюхи, где имена соответствующих полей будут без "_".
Я долго мучался с подключением к веб-сайту. Никак не хотела подключаться, 1С не видела сервера MYSQL. Оказалось что многие хостинги пускают к своей базе только через SSH тунель. Пришлось использоваться PuTTY для подключения к хостингу, а там уже как localhost обращаешься к MYSQL.
Я, на самом деле, до практической реализации не доходил - так поигрался. у меня не выкидывало при раскрытии таблиц, а поля отображались нормально, только на запросе с подчеркиванием ошибка была.
ждать когда фирма 1С исправит свой замечательный но недоделанный инструмент.
P.S. у ВИД много ещё глюков, например не получится использовать конструкцию Выбор Когда.
Полный текст исполняемого запроса - в студию. Ошибка чётко указывает на еррор в синтаксе ;)
Такие ошибки возникают если в текст запроса попадают лишние апострофы, например.
ADODB юзай, и партнеры твои его наверное тож юзают. А мож у партнеров спроси? Че голову ломать? И потом нам сюда напиши
дело в названии колонок в mysql, видимо в платформе какой то баг, из колонок типа "refresh_date" удали "_" и все заработает (Ошибки исправленные в 8.3.1.531)
(25) Если тебе источник только для чтения нужен, то сделай вьюху, это как динамический список только в терминах БД.
В запросах к mysql я пользуюсь не двойными кавычками, а знаком `.
Работает все правильно
Пример
T1.`refresh_date`,
T1.`pricelist_id`,
T1.tablename,
(32) awk, спасибо. решил для себя переименованием колонок - убрал "_" и цифры из начала. хотя недавно на 8.2 без проблем всё запускал. видимо это проблема именно 8.3
Может быть, кому-то поможет, поэтому воскрешу старую тему.
Переименовывать колонки не обязательно, к тому же это может быть очень трудоемко.
Достаточно в параметрах подключения к базе указать тип базы:
ConnectionParameters = New ExternalDataSourceConnectionParameters;
Все работает стабильно и по сей день. Используется как построчная, так и пакетная запись в таблицы MySQL, все очень довольны. :-)
Xellsing; msergeev79; Fatov_DI; fmwmf; dablack; sur0g; KazanKokos; Tommy82; ce1tic; b1waver; + 10 – Ответить
(36) mm.krasko, а где ввести эти данные ? ConnectionParameters = New ExternalDataSourceConnectionParameters;
35. primara а где ввести эти данные ? ConnectionParameters = New ExternalDataSourceConnectionParameters;
(37) Denis.S, данные вводятся программно, у меня, например, при старте системы
ПараметрыСоединения = Новый ПараметрыСоединенияВнешнегоИсточникаДанных;
далее Пользователь, Пароль и прочее и в конце:
ПараметрыСоединения.СУБД = "MySQL";
(41) Приветствую!
Столкнулся с подобной проблемой. Советы, описанные выше, не помогли. Тебе удалось решить данную проблему?))) хотя 2 года почти прошло, может вспомнишь
(43)Я смутно помню, но по-моему имена разделов надо указывать с '. А так да, проблему я решил и подключился вроде как.
В общем, сейчас 2020 год, использую платформу 8.3.16 (х64), в ней все еще такая же ошибка.
1. Предварительно добавляете таблицу в своем внешнем источнике данных;
2. В коде своей обработки при работе с этой таблице надо еще раз прописать параметры подключения и присвоить эти параметры подключения вашему внешнему источнику данных:
ПараметрыСоединения = Новый ПараметрыСоединенияВнешнегоИсточникаДанных;
ПараметрыСоединения.СтрокаСоединения ;
ПараметрыСоединения.АутентификацияСтандартная = Истина;
ПараметрыСоединения.ИмяПользователя = Логин;
ПараметрыСоединения.Пароль = Пароль;
ПараметрыСоединения.СУБД = "MySQL";
Все, после этого можете делать с вашей таблицей что угодно: либо читать данные через запрос, либо добавлять записи в вашу таблицу.
В новой редакции платформы 1С 8.2.14 появилась возможность устанавливать связь с внешними источниками данных. У меня была идея написать программу для прямой работы с базой данных на нашем сайте из 1С:Предприятия 8
В новой редакции платформы 1С 8.2.14 появилась возможность устанавливать связь с внешними источниками данных. У меня была идея написать программу для прямой работы с базой данных на нашем сайте из 1С:Предприятия 8
Очень интересная возможность новой платформы, да все никак руки не доходят ее попробовать.
Хочется уточнить один вопрос: если я установлю драйвер MySQL, а потом настрою его в "Администратор источников данных ODBC" где-нибудь в "Пользовательский DSN" или "Системный DSN", соответственно прописав там параметры подключения - смогу ли я потом подключаться к этому источнику просто по имени этой настройки? И понадобится ли заново прописывать настройки подключения к источнику данных в каждой обработке при таком подключении?
(1) я экспериментировал, параметры подключения вводил дважды:
1) в режиме конфигуратора для автоматического создания структуры таблиц
2) в режиме предприятия для отображения динамического списка записей таблиц.
Параметры вводились только один раз, они запоминаются в каком-то менеджере внешних источников данных, который доступен через "все функции" -> Стандартные -> Управление внешними источниками данных
(3) Автор пишет "Тут необходимо понимать что в обработке надо обязательно заново прописывать параметры соединения с внешней базой данных, они не хранятся в конфигурации.". Получается, что хранятся? И как потом строка подключения из обработки выглядит? Можно пример?
(5) Спасибо за дополнительную информацию. Только Ваше подключение практически идентично авторскому. И парочка примечаний "Важно". Выходит к внешнему источнику данных через подключение, описанное в (1), встроенными средствами платформы обратиться нельзя.
Ладно, пока сам не попробую приставать больше не буду.
(1) V_V_V, насчёт подключения с использованием DSN: там просто строка подключения будет иметь вид "DSN=;".
Теоретически, так можно избавиться от необходимости указывать логин/пароль в коде.
очень полезная возможность новой версии платформы представлена наглядно в очень полезной публикации этого сообщества :) спасибо :)
Да, все это безусловно хорошая вещь - внешние источники данных.
Я вначале сильно обрадовался когда узнал что 1С сделала такой механизм.
Но потом был сильно огорчен когда узнал что с этими источниками можно работать только на чтение.:(
(9) Spacer,
Ну собственно не совсем понятно в чем беда. Изменять данные через ODBC вроде всегда можно было. А тут вся фишка в том что с таблицей через запросы можно работать. Вроде запросы всегда только на чтение в 1С использовались :)
Набросаю сегодня завтра пример как я на сайте в данные меняю. Дам ссылку тут.
upd. На инфостарт не в силах перепостить сейчас, потому кому интересно как менять данные через ODBC, смотрите тут .
Попозже оформлю на инфостарте статью.
Да, все это безусловно хорошая вещь - внешние источники данных.
Я вначале сильно обрадовался когда узнал что 1С сделала такой механизм.
Но потом был сильно огорчен когда узнал что с этими источниками можно работать только на чтение.:(
Обидно что только на чтение, я уже размечтался что базу данных своего сайта смогу прикрутить и из 1С грузить информацию на сайт
Как то еще на тестовом релизе пытался связать с базой данных под управлением СУБД LETODB.Так и не получилось победить грабли вида иррациаональных чисел, и если среди DBF файлов базы имелись "пароленные" dbfки их прочитать так и не удалось, пока dbf редактором не исправил заголовок файла. а была такая надежда :(
За статью безусловно плюс. Как только появился 14 релиз 8.2 я пыталась подключить через внешние таблицы екселевский файл, пока результат отрицательный. У кого-нибудь получилось?
мне бы было интересно как подключиться к файлу базы данных на сайте (например sqlite) - не задавались таким вопросом?
(15) aximo,
Я думаю что принцип соединения аналогичный.
Сначала качаем ODBC драйвер для sqlite.
Потом из 1С прописываем сотроку соединения по аналогии
Под рукой нет такой базы чтобы проверить, но суть примерно такая.
sqlite - это файл. допустим он лежит на запароленном фтп. мне кажеться, что подключение будет несколько иное. кто знает - отпишитесь
Если база на запороленном ftp то надо вероятно другими средствами делать доступ, например поднимать ssh тонель и через него самбой шарить файл базы данных. Ну и строка подключения будет какой то такой.
Очень интресная тема.И очень полезная,если параметры подключения действительно хранятся в конфигураторе
vec435 пишет:
Очень интресная тема.И очень полезная,если параметры подключения действительно хранятся в конфигураторе
А они там не хранятся :)
Потестировал на MySQL. Вывод, бестолковая приблуда, зачем промежуточный механизм? какие плюсы использования.
Парни что я делаю не так? поставил себе последнюю платформу(8.3.5.1146), подключил базу через внешний источник данных. Если в конструкторе запросов выбираю поле без нижнего подчеркивания - то все работает. Если выбираю поле с нижним подчеркиванием, то выдает ошибку:
: Ошибка при вызове метода контекста (Выполнить)
Таблица = Запрос.Выполнить().Выгрузить();
по причине:
Ошибка выполнения запроса
по причине:
Ошибка внешней базы данных:
ошибка при выполнении запроса
по причине:
Ошибка ODBC. SQLSTATE: 42000
Номер ошибки: 1064
Описание: [MySQL][ODBC 5.1 Driver][mysqld-5.5.25]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"section_id"
FROM lesson_article T1' at line 2
а вот как на 2003 сервере х64 получить доступ к xbase через ODBC . ни в какую не могу загрузить дрова.
Всем доброго дня! Начал разбираться с использованием внешних источников. Столкнулся со следующей проблемой. Создал форму списка для таблицы MySQL. Подключение к Базе MySQL происходит, в обработчике загрузки формы делаю подключение. Но вываливается ошибка и, соответственно таблица пустая. Прилагаю скрин ошибки.
(27) bssat, непонятно почему, но у меня в в рабочем коде выскочила точно такая же ошибка как у вас на скриншоте. Пока разбираюсь в чем дело.
у менея точно такая же ошибка, походу при трансляции запроса 1с в mysql есть какойто ограничение по символам, изза етого формируется неправельный запрос (посмотри свой скрин там видно что текст запроса обрезан) если выбрать только 1-3 поля и они уместятся в запросе тогда работает, пока не разобрался с проблемой, возможно глючный ODBC , возможноно и в самой платформе глюк
(30) roha, У меня с момента написания статьи запрос работал без проблем до 26 декабря в фоновом процессе. Что произошло я не понимаю.
Рядом с поломанным запросом лежит другой, к другому ресурсу и он нормально отрабатывает команды из 1С. Пробовал вручную через Mysql front написать запрос, все работает отлично.
Что то в механизме трансляции изменилось, по-моему после обновления на 8.2.15.289
Статья ориентирована на новичков. В ней объясняется, что означает ошибка сервера MySQL №1064, рассматриваются типичные ситуации и причины возникновения этой ошибки, а также даются рекомендации по исправлению.
Рассмотрим простейший пример.
SELECT mid , time , title, artist, download, view_count, rating, vote_num FROM dle_mservice WHERE category = '1' AND approve = '1' ORDER BY time DESC LIMIT -10 , 10 ;
ERROR 1064 ( 42000 ) : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-10,10' at line 1
Сервер MySQL сообщает, что в первой строке нашего SQL запроса имеется синтаксическая ошибка, и в одинарных кавычках цитирует часть запроса с того места где начинается ошибка. Это очень полезное свойство, так как позволяет сразу определить место, которое сервер счел ошибочным. В данном случае это '-10,10', ошибка возникает из-за того, что параметр LIMIT не может быть отрицательным числом.
1. Запрос в редакторе.
Самый простейший случай - вы пишите свой запрос в редакторе. Если причина не опечатка, то:
-
Смотреть в документации синтаксис команды для вашей версии сервера MySQL.
Обратите внимание: речь идет о версии сервера MySQL, а не клиента (phpmyadmin, workbench и т.д.). Версию сервера можно узнать выполнив команду select version ( ) ;
select order from test;
ERROR 1064 ( 42000 ) : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'order from test' at line 1
MariaDB [ test ] > select ` order ` from test;
+ -------+
| order |
+ -------+
| NULL |
+ -------+
- mysql_query() выполняет содержимое как одну команду, добавление delimiter приведет к error 1064 с цитатой, начинающейся со слова delimiter
- phpmyadmin удаляет слово delimiter из-за чего возникает error 1064 с цитатой, начинающейся с переопределенного разделителя
- в MysqlQueryBrowser напротив необходимо использовать delimiter.
2. Перенос базы на другой сервер.
У вас есть дамп (т.е. файл с расширением .sql) и при попытке его импортировать вы получаете ошибку 1064. Причины:
В различных версиях набор ключевых слов и синтаксис может немного отличаться. Наиболее распространенный случай: команда create table, в которой ключевое слово type было заменено на engine. Например, если вы получаете ошибку:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'TYPE=MyISAM CHARACTER SET `utf8`' at line 29
Это означает, что вы переносите базу в пятую версию сервера MySQL, в котором ключевое слово TYPE не поддерживается и его нужно заменить на ENGINE.
Редко бываю случаи, когда перенос идет на старый (~3.23) сервер, который кодировки не поддерживает. Тогда ошибка будет иметь вид:
Часто проблемы вызваны тем, что дамп делается неродными средствами MySQL (например, phpmyadmin) из-за чего в нем могут быть BOM-маркер, собственный синтаксис комментариев, завершения команды и т.д. Кроме того при использовании того же phpmyadmin возможна ситуация при которой из-за ограничения апача на размер передаваемого файла команда будет обрезана, что приведет к ошибке 1064. Например, если вы получаете ошибку:
Значит ваш дамп содержит BOM-маркер. Это три байта в начале файла, помогающие программе определить что данный файл сохранен в кодировке UTF-8. Проблема в том, что MySQL пытается интерпретировать их как команду из-за чего возникает ошибка синтаксиса. Нужно открыть дамп в текстовом редакторе (например, Notepad++) и сохранить без BOM.
3. Некорректная работа сайта.
Если во время работы сайта появляются ошибки синтаксиса, то, как правило, причина в установке вами сомнительных модулей к вашей cms. Лучшее решение - отказаться от их использования. Еще лучше предварительно проверять их работу на резервной копии.
Пример. Движок dle 7.2, поставили модуль ,вроде бы все Ок, но:
MySQL Error!
------------------------
The Error returned was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AND approve=' 1 ' AND date < ' 2008 -10 -04 04 : 34 : 25 ' LIMIT 5' at line 1
В данном примере мы видим, что причина ошибки в отсутствии значения после "id ! php" style="font-family: monospace;"> $db -> query ( "SELECT id, title, date, category, alt_name, flag FROM " . PREFIX . "_post WHERE MATCH (title, short_story, full_story, xfields, title) AGAINST ('$body') AND id != " . $row [ 'id' ] . " AND approve='1'" . $where_date . " LIMIT " . $config [ 'related_number' ] ) ;
Далее можно искать откуда взялась переменная $row и почему в ней нет элемента 'id' и вносить исправления, но лучше отказаться от использования такого модуля (неизвестно сколько сюрпризов он еще принесет).
P.S. Если после прочтения статьи ваш вопрос с MySQL Error 1064 остался нерешенным, то задавайте его на форуме SQLinfo
Комментарий модератора.
В статье ERROR 1064 (42000) объясняется, что означает ошибка сервера MySQL №1064, рассматриваются типичные ситуации и причины возникновения этой ошибки, а также даются рекомендации по исправлению.
Отредактированно NewUse (22.11.2010 05:31:34)
while ( $row = $query -> fetchRow ( ) )
unset ( $ROW ) ;
$row [ packet ] = "$row[packet] \n " ;
$TMP_ROW = " \n " ;
if ( $row [ action ] > 0 )
$TMP_ROW .= "
$TMP_ROW .= "
$ROW [ ] = array ( VARS => $val ,
TD_PAR => "align=middle" ,
TD_CLR => DEF_CLR ) ;
}
if ( $HEADER ) {
$HEADER = false ;
$ARRAY [ ] = $TMP_HEADER ;
}
$ARRAY [ ] = $ROW ;
PHP Fatal error: Call to a member function fetchRow() on a non-object in /usr/local/www/data/index.php on line 13
Спасибо, а такой синтаксис в MySQL5 допустим?
Не подскажите, ещё один тупой вопрос от полного чайника?:
почему (и в каких случаях) в MySQL 5 на запрос:
Может вернуться ошибка, или тип, не соответствующий стандартному?
В результате к ответу при попытки применить функцию:
function FetchRow ( )
{
if ( $this -> EOF ) {
$false = false ;
return $false ;
}
$arr = $this -> fields ;
$this ->_currentRow++;
if ( ! $this ->_fetch ( ) ) $this -> EOF = true ;
return $arr ;
}
PHP Fatal error: Call to a member function fetchRow ( ) on a non-object in /usr/local/www/data/index.php on line 13
Я правда чайник, но с помощью выше рекомендованного сайта определил, что ошибка именно в результате запроса MySQL.
Не-а, ошибка в сценарии PHP, который не проверяет, что вернулся объект,
а просто дергает его метод. Ищите название объекта на 13 строке, а потом
смотрите, где он определяется. Ошибка где-то там.
так ошибка то и возникает из-за невернго формата возврата запроса из БД:
Ошибка возникает в:
Вот от сюда и вопрос, в каких случаях БД может выдавать разный ответ (вернее разный формат ответа), сейчас проверил вручную:
вот ответ:
ERROR 1054 (42S22): Unknown column 'num' in 'field list'
Отредактированно NewUse (24.11.2010 18:13:33)
Ура. Нет такого столбца. Наконец-то Вы добрались до проблемы
ALTER TABLE packets ADD num INT;
Угу, походу схема БД была не верной, ща переправлю и инструкташку под фриНИБС с Веб-мордой накатаю, там уже пришлось кое-что поменять
Подскажите, пожалуйста, как подредактировать схему, чтоб этой ошибки не возникало:
DROP TABLE IF EXISTS packets;
CREATE TABLE `packets` (
`gid` bigint ( 15 ) unsigned NOT NULL auto_increment ,
`packet` varchar ( 128 ) NOT NULL default '' ,
`deposit` double ( 16 , 6 ) NOT NULL default '0.000000' ,
`credit` double ( 16 , 6 ) NOT NULL default '0.000000' ,
`tos` tinyint ( 1 ) unsigned NOT NULL default '0' ,
`do_with_tos` tinyint ( 1 ) unsigned NOT NULL default '1' ,
`direction` tinyint ( 1 ) unsigned NOT NULL default '0' ,
` fixed ` tinyint ( 1 ) unsigned NOT NULL default '0' ,
`fixed_cost` double ( 16 , 6 ) NOT NULL default '0.000000' ,
`activated` tinyint ( 1 ) unsigned NOT NULL default '1' ,
`activation_time` int ( 10 ) NOT NULL default '2678400' ,
`blocked` tinyint ( 1 ) unsigned NOT NULL default '0' ,
`total_time_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`month_time_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`week_time_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`day_time_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`total_traffic_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`month_traffic_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`week_traffic_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`day_traffic_limit` bigint ( 15 ) unsigned NOT NULL default '0' ,
`total_money_limit` double ( 16 , 6 ) NOT NULL default '0.000000' ,
`month_money_limit` double ( 16 , 6 ) NOT NULL default '0.000000' ,
`week_money_limit` double ( 16 , 6 ) NOT NULL default '0.000000' ,
`day_money_limit` double ( 16 , 6 ) NOT NULL default '0.000000' ,
`login_time` varchar ( 254 ) NOT NULL default '' ,
`huntgroup_name` varchar ( 64 ) NOT NULL default '' ,
`simultaneous_use` smallint ( 3 ) unsigned NOT NULL default '0' ,
`port_limit` smallint ( 3 ) unsigned NOT NULL default '0' ,
`session_timeout` bigint ( 15 ) unsigned NOT NULL default '0' ,
`idle_timeout` bigint ( 15 ) unsigned NOT NULL default '0' ,
`framed_ip` varchar ( 16 ) NOT NULL default '' ,
`framed_mask` varchar ( 15 ) NOT NULL default '' ,
`no_pass` tinyint ( 1 ) unsigned NOT NULL default '0' ,
`no_acct` tinyint ( 1 ) unsigned NOT NULL default '0' ,
`allow_callback` tinyint ( 1 ) unsigned NOT NULL default '0' ,
`other_params` MEDIUMTEXT ,
`allowed_servers` varchar ( 254 ) NULL ,
`up` int ( 5 ) NULL ,
`down` int ( 5 ) NULL ,
`ippool_name` varchar ( 64 ) NULL ,
`provider_id` bigint not null default '0' ,
PRIMARY KEY ( `gid` ) ,
UNIQUE KEY `packet` ( `packet` )
) ;
Читайте также: