Adminer 1.11.0

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

Uživatelské rozhraní

Interní změny

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.

Jakub Vrána, Adminer, 3.7.2009, on-line

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í.
3.7.2009 03:41:27

ikona Jakub Vrána:

Dělala to i předchozí verze? V jakém okamžiku (po provedení jaké akce) se otazník nepřidá?
3.7.2009 04:15:51

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í :-)
3.7.2009 04:23:47

ikona Jakub Vrána:

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().
3.7.2009 04:33:59

Honza:

Do obou atributů se korektně předávají správné údaje, v případě volání stránky s URL http://servername/Adminer/PhpInfo.php je v obou proměnných hodnota "/Adminer/PhpInfo.php".
3.7.2009 04:38:12

Patrick:

Dobrý den,
také se mi to objevilo, ale také až u této verze. 1.10 byla v pořádku... Server je apache...
3.7.2009 04:35:45

ikona Jakub Vrána:

Nedaří se mi to reprodukovat na žádném serveru. Můžete si prosím stáhnout zdroják http://www.adminer.org/data/adminer-1.11.0.zip a vyzkoušet, jestli to dělá i ten?
3.7.2009 04:48:50

Honza:

Ano, projevuje se to i ve zdrojové verzi aplikace, naprosto shodně.
3.7.2009 04:53:01

ikona Jakub Vrána:

Můžete tedy prosím v index.php zavolat var_dump($SELF) po nastavení této proměnné?
3.7.2009 04:57:22

Patrick:

Můžu vám dát přístup k testovací databázi jestli by to mohlo pomoct...
3.7.2009 05:04:28

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.
3.7.2009 05:05:39

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());
3.7.2009 05:10:08

Honza:

Obsah té proměnné $_SERVER["REQUEST_URI"] se ztrácí tady:

$_SERVER = ($_SERVER ? filter_input_array(INPUT_SERVER, FILTER_UNSAFE_RAW) : array());
3.7.2009 05:09:12

ikona 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?
3.7.2009 06:00:11

Patrick:

U mně je to dobrý :)

PHP 5.2.10, webhosting C4:
http://www.webhosting-c4.cz/php5info
3.7.2009 06:07:45

Patrick:

filter.default je unsafe_raw a filter.default_flags je prázdná
3.7.2009 06:15:05

ikona 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.
3.7.2009 06:19:02

ikona 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.
3.7.2009 15:43:37

Honza:

Děkuji za pomoc, momentálně situace shodná s Patrickem, Adminer funkční. Nastavení direktiv rovněž shodné.
3.7.2009 06:22:39

ikona Jakub Vrána:

To já děkuji za pomoc s odhalením a lokalizováním chyby.
3.7.2009 06:52:19

Patrick:

výsledek var_dump

string(17) "server=localhost&"
3.7.2009 05:02:41

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
3.7.2009 06:05:30

Honza Marek:

Nejde mi stáhnout adminer z hlavního stahovacího odkazu na adminer.org. Musel jsem kliknout na mirror.
3.7.2009 08:16:06

ikona Jakub Vrána:

Ano, nějakou dobu trvá, než se nová verze na SF.net objeví.
3.7.2009 08:19:28

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?
3.7.2009 10:08:56

ikona 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í.
3.7.2009 10:17:55

ikona 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.
5.7.2009 01:07:30

Juraj:

Ahoj. Presne sa to stávalo i mne, nepodarilo sa mi však túto chybu reprodukovať.
5.7.2009 08:39:10

ikona 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.
13.7.2009 18:38:18

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...
8.7.2009 00:24:55

paranoiq:

myslím, že i bez té jednosouborovitosti už to Adminer vyhrává na celé čáře :]
8.7.2009 13:21:08

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).
9.7.2009 02:40:29

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.
8.7.2009 10:00:53

paranoiq:

ano. komentáře, které jsou schované nejsou příliš užitečné. také bych byl rád, kdyby byly zobrazené
8.7.2009 13:22:52

ikona Jakub Vrána:

Zobrazuje se v editaci struktury tabulky, asi to tak nechám.
11.7.2009 18:54:13

ikona 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í.
9.7.2009 06:28:37

ikona 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í.
13.7.2009 18:33:51

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.
9.7.2009 11:25:13

ikona Jakub Vrána:

Díky za upozornění. Už jsem si toho také všiml a opravil to v SVN.
11.7.2009 18:57:11

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.
10.7.2009 04:17:24

ikona PeTaX:

add Martin: Dělá to jen MSIE - Firef, Chrome a Opera ne.
10.7.2009 10:32:25

ikona Jakub Vrána:

Díky za upozornění, opravil jsem to v SVN.
12.7.2009 04:46:14

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.
12.7.2009 10:18:16

ikona 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.
13.7.2009 10:56:22

ikona 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ů.
15.7.2009 09:19:50

ikona Jakub Vrána:

Díky za upozornění, je to zavlečená chyba. Opravil jsem to v SVN.
15.7.2009 09:41:55

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.)
1.8.2009 08:28:20

ikona 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.
3.8.2009 11:38:02

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.
16.7.2009 04:31:47

ikona 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.
16.7.2009 08:59:54

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)
16.7.2009 09:13:11

ikona 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?
16.7.2009 13:04:07

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?
16.7.2009 13:19:59

ikona 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.
16.7.2009 13:47:34

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 :)
16.7.2009 13:55:56

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.
22.7.2009 17:04:14

ikona 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ů).
22.7.2009 17:07:20

ikona Jakub Vrána:

Místo cache tabulek jsem navigaci předělal na SHOW TABLES.
24.7.2009 11:43:20

Michal Prynych:

Dobrý den, parádní úprava, rychlost je teď skvělá. Díky.
24.7.2009 11:55:37

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?
2.8.2009 00:02:28

ikona Jakub Vrána:

Můžeš to prosím víc rozebrat? Mě přijdou obě slova stejně vhodná.
3.8.2009 11:54:05

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.
3.8.2009 13:28:27

ikona Jakub Vrána:

To by bylo roztřídit, ne?
3.8.2009 13:40:13

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á...
3.8.2009 13:51:05

ikona Jakub Vrána:

OK, změnil jsem to.
3.8.2009 14:02:11

kesspess:

Díky.
3.8.2009 14:07:46

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)
2.8.2009 16:55:37

ikona Jakub Vrána:

Články o Admineru jsou na http://php.vrana.cz/-adminer.php, což je odkázáno u každého článku.

Fóra jsou odkázaná z https://sourceforge.net/projects/adminer/support. Je to na záložce Support na stránce projektu.
3.8.2009 11:57:56

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
...
16.8.2009 14:35:22

ikona 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.
18.8.2009 12:42:02

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í.
17.8.2009 18:49:21

ikona 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.
17.8.2009 18:52:24

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ý ?
17.8.2009 19:13:42

ikona 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.
17.8.2009 19:19:47

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.
17.8.2009 19:24:09

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.
18.8.2009 01:41:33

ikona 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á.
18.8.2009 11:59:01

kozotoč:

Ok. Díky
18.8.2009 16:41:42
avatar © 2005-2024 Jakub Vrána. Publikované texty můžete přetiskovat pouze se svolením autora. Ukázky kódu smíte používat s uvedením autora a URL tohoto webu bez dalších omezení Creative Commons. Můžeme si tykat. Skripty předpokládají nastavení: magic_quotes_gpc=Off, magic_quotes_runtime=Off, error_reporting=E_ALL & ~E_NOTICE a očekávají předchozí zavolání mysql_set_charset. Skripty by měly být funkční v PHP >= 4.3 a PHP >= 5.0.