Adminer 1.11.0
Školení, která pořádám
Nová verze Admineru (dříve phpMinAdmin) přináší velkou spoustu novinek hlavně v uživatelském rozhraní. Snažil jsem se nástroj vymazlit, aby se dal používat co nejpohodlněji.
Funkční novinky
- Možnost při připojení u serveru pomocí
:/path/to/socket
určit, k jakému soketu se má připojit.
- U SQL dotazu se zobrazuje čas jeho vykonání.
- V editaci záznamu je možné používat relativní časové operace.
- Automaticky se kontroluje, zda není k dispozici nová verze.
- Provedené dotazy se ukládají do historie a zobrazují se na stránce SQL příkazu.
- Je možné zobrazit proměnné MySQL spolu s odkazem na jejich popis.
- V uživatelských oprávněních lze zvolit všechna práva.
- V exportu u výpisu tabulky se používají jen právě vybrané sloupce.
Uživatelské rozhraní
- Export dovoluje určit formát exportovaných tabulek a pro každou tabulku zvolit, zda se má exportovat nebo ne.
- Ve výpisu záznamů lze označit všechny záznamy na aktuální stránce výsledků.
- U každého záznamu už nepřekáží odkaz na jeho klonování, záznam lze klonovat jeho označením a použitím tlačítka.
- Při vytváření databáze lze vytvořit více databází najednou.
- V seznamu tabulek databáze je možné označit i pohledy a hromadně je odstranit nebo přesunout.
- Ve výpisu tabulky je výběr sloupců, podmínky a třídění zabalené.
- Při vytváření tabulky se automaticky přidávají další políčka.
- Ve výpisu interních SQL dotazů se používá znak konce řádku, aby byl kód přehlednější.
Interní změny
- Oddělil jsem JavaScriptové funkce, což umožnilo jejich kompresi a kešování.
- Před externím stylem se vždy načte i ten vestavěný. Externí styly tak nemusí opakovat definice společného stylu a nerozhodí je přechod na novou verzi.
- Vždy se zkusí použít zvýrazňování SQL syntaxe. To je externí, takže se na něj nečeká.
- Průzkumník klíčů v SQL dotazu používá oddělené připojení, aby fungovala funkce
FOUND_ROWS()
.
- Změnil jsem strukturu adresářů zdrojového kódu, který nyní používá některé externí nástroje.
- Do kódu jsem doplnil komentáře, z čehož jsem vyvodil několik drobných změn (porušení pravidla „Když to funguje, tak to neměň“).
- Cookies nyní používají předponu, takže by neměly kolidovat s cookies ostatních aplikací na stejné doméně.
- Oprava několika bezpečnostních chyb (za jedno upozornění děkuji Synopsimu).
Kontrola nových verzí
Po vydání nové verze, která opravuje nějaké chyby nebo přidává užitečnou funkčnost, mi je líto uživatelů, kteří na tuto verzi nepřejdou. Vedle RSS a upozornění e-mailem jsem proto přímo do aplikace přidal kontrolu nové verze. Ta je co nejméně agresivní – jednou za sezení se pokusí stáhnout informaci o nové verzi a zobrazit ji. Když se to nepovede (třeba proto, že není k dispozici připojení k Internetu), tak nic nezobrazí a dále už to nezkouší.
function verify_version(version) {
document.cookie = 'adminer_version=0';
var script = document.createElement('script');
script.src = 'https://www.adminer.org/version.php?version=' + version;
document.body.appendChild(script);
}
Historie
Jakýkoliv provedený dotaz umí Adminer zobrazit a upravit. V minulosti se celý dotaz předával v URL, což je jednak nehospodárné a jednak u dlouhých dotazů nefunguje v Internet Exploreru, který délku adresního řádku omezuje. Nová verze ukládá provedené dotazy do session proměnné, kterou využívají odkazy pro jejich upravení. Historie je oddělená pro každý server a vybranou databázi. Kromě toho se provedené dotazy zobrazují na stránce SQL příkazu, kde je vidět kompletní historie úprav v Admineru.
Závěr
Celkem jsem provedl více než 150 změn, jejich kompletní seznam je v SVN.
Vydal jsem verzi 1.11.1, která opravuje chybu při zapnuté extenzi Filter. Alespoň můžeme vyzkoušet, jestli funguje upozorňování na nové verze.
Diskuse
Honza:
Dobrý den,
Jakube, možná něco přehlížím v konfiguraci, ale Adminer se pokouší přistupovat na adresu http://servername/Adminer/server=servername&db=dbname
Postrádám v adrese oddělovač pro předání parametrů "?". Nevím, zda to není chybějícím nastavením URL REWRITE, používám IIS bez tohoto modulu.
Děkuju za nasměrování k řešení.
Dělala to i předchozí verze? V jakém okamžiku (po provedení jaké akce) se otazník nepřidá?
Honza:
Zda předchozí, to nevím, zkusil jsem Adminer poprvé. Otazník chybí kompletně u všech textových linků, tzn. přihlášení se provede korektně, ovšem pak (kromě volby jazyka a databáze - jsou to select boxy) není možné kliknout na žádný odkaz, protože u všech chybí otazník. Vyřešil jsem to vlastní PHP chybovou stránkou pro kód 404, která přesměruje pomocí 307 Temporary Redirect na upravené URL s otazníkem, nicméně asi to není ideální řešení :-)
Můžete prosím ověřit, zda je na serveru nastavené $_SERVER["REQUEST_URI"] a pokud ano, tak jakou má hodnotu? Pokud ne, tak zda je nastaveno $_SERVER["ORIG_PATH_INFO"]. Prozradí to třeba phpinfo().
Patrick:
Dobrý den,
také se mi to objevilo, ale také až u této verze. 1.10 byla v pořádku... Server je apache...
Honza:
Ano, projevuje se to i ve zdrojové verzi aplikace, naprosto shodně.
Jakub Vrána :
Můžete tedy prosím v index.php zavolat var_dump($SELF) po nastavení této proměnné?
Patrick:
Můžu vám dát přístup k testovací databázi jestli by to mohlo pomoct...
Honza:
Mám obdobný výsledek jako Patrick. A proaktivně :-) jsem si dovolil před nastavením $SELF ověřit obsah proměnné $_SERVER["REQUEST_URI"] - a vida, je prázdná. Tady bude asi příčina.
Patrick:
obsah $_SERVER["REQUEST_URI"] se ztrácí zřejmě někde na řádku
$_SERVER = ($_SERVER ? filter_input_array(INPUT_SERVER, FILTER_UNSAFE_RAW) : array());
Honza:
Obsah té proměnné $_SERVER["REQUEST_URI"] se ztrácí tady:
$_SERVER = ($_SERVER ? filter_input_array(INPUT_SERVER, FILTER_UNSAFE_RAW) : array());
Jakub Vrána :
Děkuji za odhalení, zatracený Filter. Můžete prosím vyzkoušet verzi http://www.adminer.org/data/adminer-1.12.0-dev.php? Pokud bude fungovat, tak bych ji ještě dnes vydal.
Pro zajímavost, jakou verzi PHP používáte? A jak máte nastavené konfigurační direktivy filter.default a filter.default_flags?
Patrick:
filter.default je unsafe_raw a filter.default_flags je prázdná
Jakub Vrána :
Děkuji, chyba je tedy zřejmě vyřešena. Zkombinovaly se dva problémy – SERVER se Filtrem zřejmě nepřepisuje za všech okolností a místo unsafe_raw jsem omylem napsal unsafe_row :-). Díky tomu se ale na chybu alespoň rychleji přišlo.
Zhruba do hodiny vydám novou verzi.
Jakub Vrána :
Novou verzi jsem skutečně vydal a zmínku o ní jsem přidal do článku. Ale kdyby si tam toho někdo nevšiml, tak to raději píšu i sem.
Honza:
Děkuji za pomoc, momentálně situace shodná s Patrickem, Adminer funkční. Nastavení direktiv rovněž shodné.
Jakub Vrána :
To já děkuji za pomoc s odhalením a lokalizováním chyby.
Patrick:
výsledek var_dump
string(17) "server=localhost&"
Dundee:
Stajná chyba i u mě (Apache2, fcgid). Vytváří to odkazy ve tvaru:
http://localhost/server=localhost
ale Adminer běží na adrese:
http://localhost/pma.php
Honza Marek:
Nejde mi stáhnout adminer z hlavního stahovacího odkazu na adminer.org. Musel jsem kliknout na mirror.
Jakub Vrána :
Ano, nějakou dobu trvá, než se nová verze na SF.net objeví.
Visitor:
Jakube, stále přidáváte nové funkcionality... Kdy se z "min" stane "my"?
Možná jinak...
Proč jste schopen do jednoho malého souboru dostat to co "My" má v několika megabytech?
Jakub Vrána :
Situace se změnila. Adminer už není nějakou chudší variantou phpMyAdminu, ale plnohodnotným nástrojem, který si lidé (samozřejmě včetně mě) vybírají proto, že se jim s ním prostě lépe pracuje. To, že je v jednom malém souboru, je jen příjemný bonus.
A v jednom malém souboru je proto, že se jednak snažím věci dělat elegantně a jednak to pořád beru jako důležité kritérium, takže jsem třeba zdrojový kód minifikoval, což má v PHP málokdo zapotřebí.
bukaJ:
Jakube,
poslal jsem Adminer na hosting a zlobí mi tam posílání SQL dotazu přes textové pole. Adminer hlásí "Nepodařilo se nahrát soubor".
Dělá to jen u zaslání kompletního DUMPu databáze, konkrétně asi 100kB textu. Když jej pošlu jako soubor, je vše OK, ale když ho pošlu jako text okopírovaný do políčka, tak to padne.
Pokud bys, Jakube, potřeboval ještě nějaké informace (např. o hostingu), napiš mi e-mail.
Juraj:
Ahoj. Presne sa to stávalo i mne, nepodarilo sa mi však túto chybu reprodukovať.
Jakub Vrána :
A nezmáčkl jsi náhodou tlačítko Provést u souboru místo tlačítka Provést pod textareou? Jejich funkce se totiž liší - horní zpracuje textareu, spodní přiložený soubor.
Asi by to chtělo jedno z nich přejmenovat, že?
Mohla by tam také být detekce toho, co je vyplněné, ale problém je, že může být vyplněné oboje.
Martin:
Bezva, nová verze už samovolně neodhlašuje :-)
Jinak někde tu zaznělo, že jednosouborovost je příjemný bonus. Myslím, že pro spoustu lidí včetně mě je to naprosto zásadní kritérium a možná i největší důvod, proč tenhle nástroj používat...
paranoiq:
myslím, že i bez té jednosouborovitosti už to Adminer vyhrává na celé čáře :]
Martin:
Hmm, tak jsem se radoval předčasně. Večer ve 22:00 jsem se přihlásil a ráno byl odhlášen (bez uzavření prohlížeče, změnila se jen IP adresa).
Jarek:
Díky moc za Adminer, od té doby, co o něm vím, jsem přestal používat phpMyAdmin.
Měl bych prosbu: bylo by možné ve struktuře tabulky vedle názvu a deklarace sloupce zobrazovat také komentáře? Přehled celé databáze je zobrazuje, tak by to bylo konzistentní. Komentáře k jednotlivým sloupcům si píšu a časem jako když je najdu.
paranoiq:
ano. komentáře, které jsou schované nejsou příliš užitečné. také bych byl rád, kdyby byly zobrazené
Jakub Vrána :
Zobrazuje se v editaci struktury tabulky, asi to tak nechám.
PeTaX:
Jakube, mám pocit, že CSV import má nějakou chybku. Pokud je csv oddělený čárkami a texty v "", tak to všechny textové řetězce zahodí.
Jakub Vrána :
Jde skutečně o fatální chybu importu, vnitřek "" se prostě zahodí. Opravil jsem to v SVN, děkuji za upozornění.
Ondřej Brejla:
Ahoj. Při úpravě tabuly má hlavní přidávací "+" tlačítko (to nahoře, vedle zaškrtávátka auto increment) anglický titulek Add next. Ostatní "+"ka u jednotlivých řádků mají český ekvivalent.
Jakub Vrána :
Díky za upozornění. Už jsem si toho také všiml a opravil to v SVN.
Martin:
Taky jeden bug report. Při editaci tabulky, pokud se klikne na přidání sloupečku (čudl +), obnoví se stránka a přidají se dva sloupečky. Není problém jeden umazat, a v předchozí verzi to bylo ok.
PeTaX:
add Martin: Dělá to jen MSIE - Firef, Chrome a Opera ne.
Jakub Vrána :
Díky za upozornění, opravil jsem to v SVN.
Jakub Sochor:
Zdravím,
Adminer se mi velmi líbí, ale bohužel mi u něj vadí jedna věc, která je dostupná v PhpMyAdminu a to tato:
Když mám tabulku a kliknu na Nová položka, tak by vedle názvů sloupců mohl být zobrazen také jejich datový typ. Bylo by to přehlednější, při přidávání do nějáké tabulky, kterou moc neznám a chci tam přidat jednu položku.
Jakub Vrána :
Ve viditelné oblasti by to podle mě moc překáželo, tak jsem to přidal alespoň do title názvu sloupce. Na stejném místě se to zobrazuje i ve výpisu dat.
Jiří Pospíšil:
Dobrý den, při nastavování výchozích hodnot sloupců Adminer správně výchozí hodnoty nastaví, ale později s nima nepracuje, resp. při manuálním vkládání nové položky je pole s nastavenou výchozí hodnotou prázdné a stejně tak při opětovné editaci výchozích hodnot sloupců.
Jakub Vrána :
Díky za upozornění, je to zavlečená chyba. Opravil jsem to v SVN.
pojízdná kočka:
Ono je stejně divné, proč nemůžou být výchozí hodnoty rovnou na stránce pro pozměnění tabulky - navíc, když tam můžou být komentáře... (které jsou z hlediska databáze nedůležité).
Navíc se s tím pojí další potíže - vezměte např. tento příklad: Mám tabulku, ve které mám pole typu varchar s nějakou řetězcovou výchozí hodnotou. Pak se rozmyslím, že místo varchar chci třeba typ int nebo datetime. Při pokusu o uložení změněné tabulky MySQL zařve "nesprávná výchozí hodnota pro pole (to a to)" a uživatel nemá z daného formuláře šanci tu výchozí hodnotu změnit. (Ano, může sice upravit nabízené SQL, ale to už jsme kvalitativně klesli z příjemného point-and-click nástroje na databázový shell, takže doufám, že tohle nebude nikdo namítat.)
Jakub Vrána :
Já s tím souhlasím, proto je taky integrace výchozích hodnot do úpravy tabulky v oficiálním TODO.
Tento konkrétní problém se dá vyřešit kromě úpravy SQL také tak, že se v jiném tabu otevře úprava výchozích hodnot, tam se původní hodnota vymaže a potom se struktura tabulky uloží znova (stačí refresh stránky). Krkolomné to je samozřejmě taky.
Michal Prynych:
Dobry den, vsiml jsem si, ze pro kazde zobrazeni stranky se vyuziva prikaz SHOW TABLE STATUS pro zobrazeni leveho menu, pokud, ale mam dost velkych tabulek, tento prikaz trva velmi dlouho, nedalo by se to vyresit nejak jinak? Pripadne nejak kesovat? Jinak je to skvely nastroj, diky za nej.
Jakub Vrána :
Kešuje se seznam databází, jehož získání taky může trvat dlouho. Tuto keš je navíc celkem snadné promazávat. Seznam tabulek se mi kešovat nechce, protože tam může dojít ke změně na více místech, vyloučit se nedá ani změna mimo Adminer, která se nedá detekovat.
Můžete prosím uvést nějaká čísla? Kolik tabulek, jakého typu a jak dlouho trvá získání jejich seznamu. Čas prozradí třeba SQL příkaz v Admineru.
Michal Prynych:
Je mi jasne, ze je to ponekud ozehava vec, protoze tabulky se mohou menit casteji nez databaze. Na druhou stranu si rikam, jak moc tu zmenu potrebuju opravdu aktualne videt?
Jinak tabulek je asi 160, vetsinou innodb, celkova velikost databaze je neco pres 10 gigabajtu. A to ziskavani seznamu trva mezi 3 - 5 sekundami. Bohuzel nemam zadne zkusenosti s optimalizaci SHOW TABLE STATUS ani optimalizaci information_schema (mimochodem dotazy na information_schema primo trvaji uplne stejne)
Jakub Vrána :
Mě získání seznamu 150 prázdných InnoDB tabulek v databázi trvá kolem 13 ms. Zkuste prosím vyexportovat jen strukturu tabulek a zjistit, jak dlouho trvá jejich výpis (nejlépe na stejném serveru, ale v jiné databázi).
Můžete prosím také zjistit, jak dlouho trvá příkaz SHOW TABLE STATUS LIKE na jednotlivé tabulce?
Michal Prynych:
skutecne, na prazdnych tabulkach na stejnem stroji v jine db je to 0.013 s (coz je moc pekne a cely adminer je pak krasne svizny :)
na jednotlivych tabulkach je to dost ruzne, nejvetsi tabulka, ktera ma nejvice indexu trva necele 2 sekundy. druha nejvetsi tabulka, ktera ma jen primarni klic trva 0.3 sekundy a zbytek tabulek, ktere jsem nahodne zkusil maji 0.001
doted jsem vubec netusil, ze SHOW TABLE STATUS je zavisly na datech v tabulce. je mozne ze nektere enginy tyto informace neudrzuji, ale dopocitavaji je?
Jakub Vrána :
Také to je pro mě novinka. O tom, že by se informace dopočítávaly, nevím. Naopak InnoDB přesný počet nezná a v SHOW TABLE STATUS uvádí jen přibližnou hodnotu. Přesto je ale u velkých tabulek pomalý, viz např. http://lists.mysql.com/mysql/179735.
Zatím jsem alespoň do navigace přidal zavolání flush(), aby se zobrazila hlavní část stránky. Zavedení tabulkové cache zvážím.
Michal Prynych:
Skutecne je to tak, zkusil jsem tu jednu tabulku naplnit a SHOW TABLE STATUS se velmi zpomalil. Zda se ze MyISAM timto netrpi. Kazdopadne diky za diskusi :)
Igor Aufricht:
Mám rovnaký problém, pri prítomnosti veľkých InnoDB tabuliek (konkrétne 1,5 mil. záznamov, 1GB dát) trvá načítanie ľubovoľnej stránky v rámci Adminera rádovo sekundy. Spomalenie vzniká aj po zvolení databázy (z ponuky vľavo), keď sa načíta zoznam tabuliek.
Veľmi citeľné je to na produkčnom (vyťaženom) serveri, kedy sa čas načítavania stránok zväčšuje niekedy až na minúty.
Cache tabuliek by teda zrejme pomohla ľudom pracujúcim s InnoDB tabuľkami s veľkým množstvom dát. Mne osobne by napríklad vyhovovalo riešenie s cache a tlačidlom "refresh" pre obnovenie zoznamu tabuliek.
Vďaka.
Jakub Vrána :
Cache tabulek tedy zavedu, je to skutečně nepříjemný problém. Obnovovat se bude při všech změnách tabulek a pak taky na stránce s výpisem informací o tabulkách v databázi (kde se zobrazuje i přibližný počet záznamů).
Jakub Vrána :
Místo cache tabulek jsem navigaci předělal na SHOW TABLES.
Michal Prynych:
Dobrý den, parádní úprava, rychlost je teď skvělá. Díky.
kesspess:
Zdravím.
Ve verzi 1.11.1 (nevím, zda i dříve) se u výpisu dat tabulky zobrazuje český překlad "Setřídit" u třetí zobrazovací oblasti. Jsem spíše pro "Seřadit" co do významu slova, co ty na to?
Jakub Vrána :
Můžeš to prosím víc rozebrat? Mě přijdou obě slova stejně vhodná.
kesspess:
Nejsem češtinář, ani jsem nehledal ve slovníku, ale slovo "Setřídit" mi evokuje to, že se data uspořádají do nějakých tříd (skupin) podle zadaných kritérií, kdežto "Seřadit" mi jasně říká, že se data budou řadit.
kesspess:
"Setřídit" a "roztřídit" se podle mě liší pouze ve směru provádění akce, akce samotná by měla být stejná...
pojízdná kočka:
Jakub: (technická) Nic proti tomu, že píšeš další a další články o phpMinAdminu/Admineru. Ale s tím, jak přibývají, začíná být (myslím si) čím dál těžší orientovat se v tom, co ti jednotliví lidé říkají v diskuzi, resp. reagovat na to.
* Co třeba nějaký prťavý navigační panel, který by shrnoval všechny články o Adminerovi (buď jako plovoucí nahoře, nebo dole, ve stylu seriálů jako třeba na Intervalu)?
* Centrální diskuze, klidně v phpBB, byla by? (koukala jsem na sourceForge, ale asi jsem pidlovoká, nenašla jsem ji)
Prdlořeznictví Krkovička, n. p.:
Ve výpisu tabulek Adminer nabízí parametrické vyhledávání. Jeden z operátorů je IN(), který se od ostatních odlišuje tím, že to, co je v něm, není jedna hodnota (která by se dala uzavřít do uvozovek), ale výčet hodnot.
Zjevně, Adminer má jakousi kontrolu tohoto parametru, ale vykazuje "legrační" chování pro některé parametry, např.:
IN (1, "Y") ---> IN (1,) a skončí chybou (i pro textová pole)
IN (1, CHAR(50)) ---> IN (1, 50), což není to, co uživatel měl na mysli
IN (1,"2a") ---> IN (1, 2) dtto
...
Jakub Vrána :
Vyžaduje to buď všechny prvky uzavřené do apostrofů nebo do uvozovek. Pokud tomu tak není, tak se vyhází všechno kromě čísel a čárek. Nic s tím dělat asi nebudu.
Michal:
Zdravím. Měl bych pár dotazů ohledně Admineru.
V souboru index.php je nastaven error_reporting na E_ALL & ~E_NOTICE. Při zobrazení výpisu všech chyb (E_ALL) se vypíšou oznámení o nedefinovaných indexech.
Rád bych věděl, jestli skrytí těchto varování je dostatečné za to, že se nemusí proměnné testovat na isset(..) a kód je zjednodušen. Případně jestli by se nějakým způsobem dal změnit typ vypisovaných chyb a mohlo dojít k problémům s bezpečností.
Jakub Vrána :
Adminer důsledně inicializuje všechny proměnné (zkontrolováno nástrojem http://code.google.com/p/php-initialized/), bezpečnostní riziko tedy nehrozí. E_NOTICE je vypnuto proto, že PHP upozorňuje i na práci s neinicializovaným prvkem inicializovaného pole, což je z pohledu bezpečnosti v pořádku.
Michal:
Děkuji za rychlou reakci.
Pokud do formuláře při neodeslání vypíši zpět vyplněné hodnoty přes např. <input type="text" .. value="$_POST[input]"> tak při (error_reporting=E_ALL & ~E_NOTICE) nebude vypsáno hlášení o neinicializaci prvku. Jaký je tedy obsah tohoto inputu ? Je v něm ono hlášení a je pouze skryto a input tedy není ve skutečnosti prázdný ?
Jakub Vrána :
Nedefinovaná proměnná v PHP obsahuje hodnotu NULL, která se při použití v kontextu řetězce převede na prázdný řetězec. Příklad ale obsahuje jiné chyby:
1. $_POST[input] by hledalo konstantu input. Mimo řetězec je potřeba psát $_POST["input"].
2. Vstup od uživatele je nedůvěryhodný, je tedy potřeba ho při vypsání do HTML ošetřit např. funkcí htmlspecialchars().
S Adminerem nicméně tato debata nijak nesouvisí, proto další dotazy směruj třeba na http://diskuse.jakpsatweb.cz/index.php?act…&forum=9.
Michal:
Moc jste mi pomohl. Napsal jsem to do této diskuse pouze proto, že jsem na to narazil v situaci s Adminerem a věděl, že mi odborník jako vy podá jasné vysvětlení. Ještě jednou moc děkuji.
kozotoč:
Pěkný den,
Poslušně hlásím chybu:
Jedná se o poněkud méně frekventovaný případ, kdy chce uživatel odstranit celou databázi.
* možná jsem se špatně díval, ale nevidím, že by Adminer tuto možnost měl
* to, jestli by ji mít měl (a dovolit na jeden klik (a potvrzení)) zničit vše, toť filosofická otázka a rád bych to oddělil toho praktického.
* Pokud v SQL oknu v dané databázi napíšu "DROP DATABASE moje_databaze;", tak Adminer příkaz splní, ale hned nato v levém sloupci, tam, kde bývá výpis tabulek vypíše PHP chybovou hlášku:
Fatal error: Call to a member function g() on a non-object in C:\moje\php\www\adminer\index.php on line 251
PhpMyAdmin v případě zničení celé databáze přesměruje "o úroveň výš" -na databázový server se seznamem databází. Toto bych si pro tuto akci dovolil navrhnout i pro Adminera.
Jakub Vrána :
Databáze se dá odstranit pomocí odkazu Pozměnit databázi.
Chybu jsem zkultivoval.
Přesměrovat o patro výš mi z SQL příkazu nepřijde příliš rozumné, protože hned další příkaz může databázi zase vytvořit. V exportech je poměrně běžně za sebou DROP DATABASE; CREATE DATABASE. Při klikacím odstranění se o patro výš přesměrovává.
Diskuse je zrušena z důvodu spamu.