Rst Sql Post клиент.
 

Приветствую!

Всем хорош оригинальный скуль шелл от рст, тут тебе и удобство работы и не очень большой размер, но вот незадача - авторы сделали его работающим только GET запросами.
Все знают почему это плохо, описывать не стану.

При взломе одного забугорного сервака у меня была задача подключиться к внутреннему серверу БД.
Он имел локальный ip и у меня был рутовый пасс на скуль. Шелл от Маднета корректно подключился и все было прекрасно, но вот при апдейте полей madshell иногда или сбрасывал ВСЕ(!) значения или же вообще не апдейтил их.
По привычке залив RST SQL шелл, я обнаружил, что он тут он отказываеться работать. Быстро перебрав по совету знакомых все SQL шеллы, я обнаружил, что работают только те что используют POST.
Почему - времени выяснять не было...

Я попросил Macro переписать скульшелл с гета на пост, что он и сделал.? за что ему РЕСПЕКТ и благодарности. Также респект Diagen, за то что терпит кучу вопросов по синтаксису Пыха=)
Надеюсь Вам будет приятно работать с обновленным RST SQL клиентом!

О всех глюках шелла (а как без них ;) ) прошу писать в этой теме, или в ПМы.

З.Ы. Исправлены баги, данные Тохой и ведеться переработка механизма дампа.

Завершено формирование механизма дампа.

1) диз: хромает на индексе и на выводе, в районе полей Edit и там где названия колонок ибо белый и голубоватый на сером форне незачёт) ярко-красный на кнопках я бы светлосерым заменил) поле "тип" данных тож не катит во всех вкладках) цвет при ошибке выедает глаза) при создании новой таблицы тож белый не катит) "Action: Успешно вставлено строк (1)
PHP-код запроса:"
тож не то)

2) часто было что надо апдейтить колонку passwd и поэтому возникал конфликт с переменной пасса для коннекта к бд (тоже passwd), поэтому лучше в кукисы запихнуть
а так ничё вроде)

3) в начало каждого запроса желательно пихнуть нуллбайт в камменах /* */ чтоб запросы не логировались

дамп баз :
а если safe_mode или open_basedir , если не предопределена папка /tmp то дамп не пройдет.

mysql_create_db() http://us2.php.net/manual/ru/function.mysql-create-db.php
у меня этой функции на php 5 тоже нет.

если включить error_reporting сразу нотайсов 10 выкидывается.

с кодировкой у меня не хотят браузеры работать, konqueror не понимает javascript такой.
это то что на первый взгляд бросается в глаза.

Все учтем! Тестим тестим!

Да на мой взгляд это лучшее решение.

Как аналог погу предложить такой вариант, на моем опыте базы 20-30 лямов записей очень сложно долго и нудно дампяться, основная проблемма возникает когда переваливаем за 10кк обычные дамперы слить не могут, из-за так как пролистывать поток тех данных им приходиться, в данном случае всегда выручал phpmyadmin так вот если можно было бы сделать дамп таким образом:
Общий count() делим к примеру на 20к и сливаем лимитом по 20к всю базу не забывая по пути юзать gizp -9, а данном способе будет минимальная нагрузка на бд, по сравнению например mysqldump ом, И Малое время затраченное на операцию.

Если я не прав поправьте меня, хотел бы услыщать ваш опыт слив больших баз(особенно когда сам сервак находиться не на localhost а на стронем серваке во внутренней локалке).

Я сливал огромные базы сайпексом. Без проблем. И восстанавливал у себя на денвере. Кэш, если не сложно, продолжай давать рекомендации.
Надеюсь их мне можно вынести из моа и дать автору? ;)

Огромные базы.
Скайпекс, была такая трабла бд была в локалке и сливать можно было разумееться тольео с сервака используя скрипт либо проставить сокс и работать через тунель, порты там не биндились не при каких условиях,
А Скайпекс, сливал первые 500 метров примерно и срубался (тоесть при сливе любой базы он останавливался примерно на 467мб). С чем это связанно я могу предположить что в принцыпе при дампе со строннего ресурса вся инфа идет либо в оперативку либо в темп файл так вот при больших размерах он просто начинает дропаться, так же проблемма исполнения скприптов на php когда 1 процесс висит долгое время, его палит либо какойто софт автаматом рубящий по времени исполнения либо админ либо вообще настройки php не позваляют запускать на долго процесс, поэтому слив маленькими партиями и потом дальнейшее архивирование на мой взгляд самый разумный и беспалевынй способ.

эт еще про дамп ) кароч если одновременно дампить на одном серваке несколько раз то естественно так как используется постоянное имя дампа в тмп то дамп будет перезаписваться и в итоге фиг пойми че уйдет в браузер ;)

поток в браузер всегда не очень хорошее решение лучше слить на серв а потом уже с серва самостоятельно.

[cash] пошел смотреть сорцы Simple PHP Mysql client

Полностью с тобой согласен. В том же дампере показали прекрасную возможность так делать. Плюс у них еще и сжатие идет дампа. А это скорость и экономия траффика.