nicht angemeldet
MySql DB-Vers.5.1.39 'kein Zugriff'
Moinser,
zu meiner bereits bestehenden Datenbank habe ich eine weitere angelegt, auf die ich irgenwie nicht zugreifen kann.
Der Name meiner bisherigen Datenbank lautete (Beispiel)
db123456
Der Name der zusätzlichen Datanbank hat den Namen:
db123456_1
Das Passwort ist das gleiche.
So greife ich auf die Datenbank zu:
mysql_connect("localhost", "db123456", "mustermann"); = Funktioniert
mysql_connect("localhost", "db123456_1", "mustermann"); = Funktioniert nicht.
Es erscheint folgende Fehlermeldung:
Warning: mysql_connect() [function.mysql-connect]: Access denied for user 'db123456_1'@'localhost' (using password: YES)
Hat einer ne Idee wodran das liegen kann, oder was ich nochmal ausprobieren könnte?
Vielen Dank vorab
Gruß
-
Hello,
zu meiner bereits bestehenden Datenbank habe ich eine weitere angelegt, auf die ich irgenwie nicht zugreifen kann.
Wie/womit hast Du die Datenbank denn angelegt?
Hast Du einen Shell-Zugriff auf den Rechner?Üblicherweise wird eine neue Datenbank immer erst mit root@localhost ohne Passwort angelegt.
Je nach Installation stehen dann auch nich Service-User in der Rechtetabelle, damit Updates und Datensicherungen durchgeführt werden können.
Du solltest Dir also die Tabelle "user" der Datenbank "mysql" ansehen, was darin für User stehen.
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hallo,
So greife ich auf die Datenbank zu:
mysql_connect("localhost", "db123456", "mustermann"); = Funktioniert
mysql_connect("localhost", "db123456_1", "mustermann"); = Funktioniert nicht.Es erscheint folgende Fehlermeldung:
Warning: mysql_connect() [function.mysql-connect]: Access denied for user 'db123456_1'@'localhost' (using password: YES)Hat einer ne Idee wodran das liegen kann, oder was ich nochmal ausprobieren könnte?
am Benutzer. Steht doch da. Wie wäre es mit dem Benutzer "db123456"? Nur weil Du eine neue Datenbank angelegt hast, muss noch lange kein gleichnamiger Benutzer angelegt worden sein, der außerdem noch automatisch das gleiche Passwort erhält wie der bestehende Benutzer und für den Zugriff auf die neue Datenbank berechtigt wird.
Was sagt die Dokumentation Deines Hosters über den Datenbankbenutzer für von Dir zusätzlich angelegte Datenbanken?
Warum verwendest Du die veralteten und wenig leistungsfähigen mysql_*-Funktionen? Empfohlen wird die mysqli-Erweiterung.
Freundliche Grüße
Vinzenz
-
Hi!
Warum verwendest Du die veralteten und wenig leistungsfähigen mysql_*-Funktionen? Empfohlen wird die mysqli-Erweiterung.
Übrigens, seit PHP 5.3 arbeitet mysqlnd im Hintergrund für mysql, mysqli und PDO_mysql. Der Unterschied zwischen mysql und mysqli ist mehr oder weniger nur noch die Oberfläche und der Funktionsumfang. Eine Beurteilung der Leistungsfähigkeit sollte meiner Meinung nach vorwiegend am eigenen Bedarf gemessen werden. Für Feld-Wald-und-Wiesen-Scripte ist die mysql-Extension durchaus leistungsfähig genug - zwar älter als mysqli, aber nicht veraltet. Man könnte sogar sagen, dass durch den geänderten Unterbau sie nun beide gleich alt sind.
Lo!
-
Moin!
Warum verwendest Du die veralteten und wenig leistungsfähigen mysql_*-Funktionen? Empfohlen wird die mysqli-Erweiterung.
Übrigens, seit PHP 5.3 arbeitet mysqlnd im Hintergrund für mysql, mysqli und PDO_mysql. Der Unterschied zwischen mysql und mysqli ist mehr oder weniger nur noch die Oberfläche und der Funktionsumfang. Eine Beurteilung der Leistungsfähigkeit sollte meiner Meinung nach vorwiegend am eigenen Bedarf gemessen werden. Für Feld-Wald-und-Wiesen-Scripte ist die mysql-Extension durchaus leistungsfähig genug - zwar älter als mysqli, aber nicht veraltet. Man könnte sogar sagen, dass durch den geänderten Unterbau sie nun beide gleich alt sind.
Es gibt etliche Features, die man nur mit mysqli nutzen kann. Das hat mit dem Unterbau gar nichts zu tun - auch vor PHP 5.3 wurde eine MySQL-Client-Bibliothek eingebunden, von der die MySQL-Extension einfach weniger Features genutzt hat.
- Sven Rautenberg
-
Hi!
Für Feld-Wald-und-Wiesen-Scripte ist die mysql-Extension durchaus leistungsfähig genug
Es gibt etliche Features, die man nur mit mysqli nutzen kann.Ja, und? Wenn sie einer braucht, muss er eben mysqli nehmen. Diese Features sind durchaus nett und nützlich, keine Frage. Viele brauchen aber nur einfache Abfragen und dann sind sie mit mysql bestens bedient. Was ist denn der Vorteil, mysqli zu nutzen, wenn man die zusätzlichen Features nicht benötigt?
Lo!
-
Moin!
Für Feld-Wald-und-Wiesen-Scripte ist die mysql-Extension durchaus leistungsfähig genug
Es gibt etliche Features, die man nur mit mysqli nutzen kann.Ja, und? Wenn sie einer braucht, muss er eben mysqli nehmen. Diese Features sind durchaus nett und nützlich, keine Frage. Viele brauchen aber nur einfache Abfragen und dann sind sie mit mysql bestens bedient. Was ist denn der Vorteil, mysqli zu nutzen, wenn man die zusätzlichen Features nicht benötigt?
Du meinst, es ist reichlich überflüssig, diesen einen zusätzlichen Buchstaben zu tippen, nur weil man den auch weglassen kann?
Es wird seinen Grund haben, warum man die zusätzlichen Features nicht in die mysql-Extension hineingetan hat, sondern eine eigenständige Extension programmierte. Und es ist zu vermuten, dass mysql irgendwann als Feature nicht weiter entwickelt wird, also auf die Abschussliste kommt.
MySQLi erlaubt, ausweislich der Dokumentation, den Zugriff auf Features von MySQL ab Version 4.1. Das ist schon eine extrem alte MySQL-Version. Es gibt eigentlich keinen Grund, auf diese Features schon direkt im Programmcode zu verzichten, indem man grundsätzlich die falsche Extension einsetzt.
Verstehe auch nicht, wieso du plötzlich genau in diese Richtung argumentierst.
- Sven Rautenberg
-
Hi!
Du meinst, es ist reichlich überflüssig, diesen einen zusätzlichen Buchstaben zu tippen, nur weil man den auch weglassen kann?
Es geht mir nicht um diesen einen Buchstaben sondern um die Komplexität, die das mysqli mitbringt und damit auch die möglichen Wege zur Lösung und die dabei vorhandenen potentiellen Fehlerquellen.
Es wird seinen Grund haben, warum man die zusätzlichen Features nicht in die mysql-Extension hineingetan hat, sondern eine eigenständige Extension programmierte. Und es ist zu vermuten, dass mysql irgendwann als Feature nicht weiter entwickelt wird, also auf die Abschussliste kommt.
Das sehe ich als unrealistisch an, weil damit jede Menge vorhandener Code unbrauchbar gemacht wird. So unklug sind die PHP-Entwickler nun auch wieder nicht. Wenn es so weit kommen sollte, so wird das garantiert rechtzeitig genug bekannt gegeben. Wenn ich mir die PHP-6-Entwicklung ansehe, wird man Jahre Zeit haben, den Umstieg vorzubereiten und zu propagieren.
MySQLi erlaubt, ausweislich der Dokumentation, den Zugriff auf Features von MySQL ab Version 4.1. Das ist schon eine extrem alte MySQL-Version. Es gibt eigentlich keinen Grund, auf diese Features schon direkt im Programmcode zu verzichten, indem man grundsätzlich die falsche Extension einsetzt.
Verstehe auch nicht, wieso du plötzlich genau in diese Richtung argumentierst.
Es ist kein plötzlich. Mein Prinzip ist nicht, nur weil etwas da ist, muss man es verwenden, sondern darüber nachzudenken, ob einem die Verwendung Vorteile, Nachteile oder überhaupt nichts bringt. Ich sehe für mysql vs. mysqli einfach keinen Grund, warum ich gegen das Bewährte argumentieren soll, nur weil es was neues (in diesem Fall wegen des gleichen Unterbaus nur was erweitertes) gibt, mit mehr Features, die weder angewendet werden sollen noch verstanden werden.
Welche Features sind es denn, die für 0815-Anwendungen interessant sein könnten?
-
Multiquerys?
Selten. Und wenn, dann muss man sich mit einem komplexen Ergebnisabholungsprozess rumschlagen. -
Stored Procedures?
Es fällt ja vielen schon schwer, normale Statements zu formulieren. -
Prepared Statements?
Haben eine meiner Meinung nach recht ungewöhnliche Umsetzung, wie man Variablen binden muss. Dieses Konzept muss man auch erst einmal verstehen. Und es schränkt insoweit ein, als dass man jede Variable (inklusive einzelne Array-Elemente) einzeln angeben muss und nicht Arrays übergeben kann. P.S. sind auch für Massendateneinfügungen vorgesehen. Doch man kann keine Zeilen-Arrays an das Execute übergeben (oder vorher binden) (geschweige denn, ein Array mit Zeilenarays einem einzigen Execute-Aufruf übergeben). Man muss das Werte aus dem Array vor dem Execute erst noch auf die gebundenen Variablen kopieren. Zudem wird das Ergebnis auch in einzelnen Variablen geliefert und nicht gebündelt als Array/Objekt, um es gemäß EVA-Prinzip später verwenden zu können. Sicher kann man hier mit Hilfe der SPL und einem Iterator ein Array simulieren - zum Preis weiterer Komplexität. Sinnvoll, wenn man es braucht, aber nicht pauschal. - Ich könnte mitgehen, wenn man PDO propagiert, denn da ist das P.S.-Handling wesentlich benutzerfreundlicher implementiert. - Sicherheit? Ist eine nette Nebenwirkung, aber nicht der primäre Zweck. Man erkauft sie sich mit der erhöhten Komplexität des P.S.-Handlings.
Wie gesagt, das sind (abgesehen von der Implementierung) alles wunderbare Features an sich - für den der sich braucht. Und ich werden einen Teufel tun, sie jemandem auszureden, wenn er sich dafür entschieden hat, wenn er Bedarf dazu hat, und wenn die Vorteile die Nachteile bei ihrer Verwendung - konkret für den Einsatzzweck beurteilt - überwiegen. Für eine pauschale Empfehlung habe ich jedoch nicht genügend stichhaltige Argumente.
Lo!
-
Moin!
Es geht mir nicht um diesen einen Buchstaben sondern um die Komplexität, die das mysqli mitbringt und damit auch die möglichen Wege zur Lösung und die dabei vorhandenen potentiellen Fehlerquellen.
mysqli ist genauso komplex, wie mysql. Man kann es prozedural anwenden, und es verhält sich genau gleich.
Ist also in dieser Hinsicht wirklich nur ein Buchstabe mehr zu tippen.
Aber danach? ...
Welche Features sind es denn, die für 0815-Anwendungen interessant sein könnten?
- Multiquerys?
Selten. Und wenn, dann muss man sich mit einem komplexen Ergebnisabholungsprozess rumschlagen.
Multi-Querys sind für manche Dinge unabdingbar. Nicht nur für mehr als einen Query in einem String. Beispielsweise auch für ...
- Stored Procedures?
Es fällt ja vielen schon schwer, normale Statements zu formulieren.
Stored Procedures sind aus meiner Sicht in den meisten Projekten aber tatsächlich nicht wirklich angebracht. Das ist wirklich nur dann sinnvoll, wenn man auf die Datenbank aus mehreren verschiedenen Sprachen zugreift und gewisse Regeln forcieren muss.
- Prepared Statements?
Haben eine meiner Meinung nach recht ungewöhnliche Umsetzung, wie man Variablen binden muss. Dieses Konzept muss man auch erst einmal verstehen.
Ich glaube, die Argumentation pro MySQLi ist auch prophylaktischer Natur. Es wäre blöd, wenn man sämtlichen Code mitten im Projekt umstellen muss, nur weil plötzlich ein Feature gebraucht wird, das nurmit mysqli funktioniert.
Wie gesagt, das sind (abgesehen von der Implementierung) alles wunderbare Features an sich - für den der sich braucht. Und ich werden einen Teufel tun, sie jemandem auszureden, wenn er sich dafür entschieden hat, wenn er Bedarf dazu hat, und wenn die Vorteile die Nachteile bei ihrer Verwendung - konkret für den Einsatzzweck beurteilt - überwiegen. Für eine pauschale Empfehlung habe ich jedoch nicht genügend stichhaltige Argumente.
Es gibt genau ein stichhaltiges Argument pro mysqli: Man kann damit mehr machen, als mit mysql, und es soll auch performanter sein, ansonsten verhält es sich genau gleich.
Und wenn mysql und mysqli funktional bei den Punkten, die beide abdecken, sich identisch verhalten, dann gewinnt die Variante, die mehr potentielle Möglichkeiten bietet und schneller ist. Und das ist mysqli.
Das reicht mir als Grund für eine pauschale Empfehlung aus.
- Sven Rautenberg
-
moin,
Stored Procedures sind aus meiner Sicht in den meisten Projekten aber tatsächlich nicht wirklich angebracht. Das ist wirklich nur dann sinnvoll, wenn man auf die Datenbank aus mehreren verschiedenen Sprachen zugreift und gewisse Regeln forcieren muss.
was hat das mit verschiedenen sprachen zu tun ? es ist doch leztlich vollkommen wurscht, ob ich anwendungen habe, die die gleiche sprache benutzen oder aber andere. ich will bestimmte dinge nur an einer stelle festlegen, und zwar ganz unabhängig von der anwendung, weil ich ganz einfach darüber die kontrolle haben will. und die performance spielt auch noch eine gewisse rolle...
Ilja
-
Moin!
Stored Procedures sind aus meiner Sicht in den meisten Projekten aber tatsächlich nicht wirklich angebracht. Das ist wirklich nur dann sinnvoll, wenn man auf die Datenbank aus mehreren verschiedenen Sprachen zugreift und gewisse Regeln forcieren muss.
was hat das mit verschiedenen sprachen zu tun ? es ist doch leztlich vollkommen wurscht, ob ich anwendungen habe, die die gleiche sprache benutzen oder aber andere. ich will bestimmte dinge nur an einer stelle festlegen, und zwar ganz unabhängig von der anwendung, weil ich ganz einfach darüber die kontrolle haben will. und die performance spielt auch noch eine gewisse rolle...
Es gibt den Ansatz, sämtliche Datenkontrolle zentral in der Datenbank zu lagern. Das ist prima, wenn man eine Herde von DBAs hat, und sich ersparen will, diese ganze Logik in seiner zugreifenden Applikation zu programmieren.
Der Nachteil ist, dass diese Check-Logik unter Umständen ein hartes Performance-Limit setzt und ziemlich effektiv verhindert, dass man die speichernde Datenbank mal so einfach austauschen kann. Ebenfalls müssen sich die Programmierer zur Realisierung von Daten- und Zugriffslogik intensiv mit mindestens zwei Sprachen auseinandersetzen, und werden eventuell doch feststellen, dass "es" in der Datenbank schon zu spät ist, irgendeinen Daten-Fehler festzustellen und zu bemängeln.
Deshalb ist der einfachere Ansatz, die Datenzugriffslogik in der programmierten Applikation zu realisieren, und die Datenbank im Prinzip nur als Speicher zu benutzen, eventuell angereichert um so obskure Features wie Joins. Es gibt ja auch schon zahlreiche Projekte, die Datenspeicher ohne SQL herstellen - das ganze läuft dann unter dem Begriff "NoSQL".
- Sven Rautenberg
-
moin,
Es gibt den Ansatz, sämtliche Datenkontrolle zentral in der Datenbank zu lagern. Das ist prima, wenn man eine Herde von DBAs hat, und sich ersparen will, diese ganze Logik in seiner zugreifenden Applikation zu programmieren.
mal davon abgesehen, dass man von "gar nicht" bis "sämtliche" noch einige zwischenräume hat, um sp einzusetzen. aber noch mal die frage, was hat das mit mehreren sprachen zu tun ?
dass man die speichernde Datenbank mal so einfach austauschen kann.
das wäre so, als wenn ich mal schnell die sprache der applikation wechseln wollte. was ich in java programmiert habe, sollte dann auch mal bitte in Modula-2 funktionieren, ohne großen aufwand zu betreiben. eine datenbank ist weit mehr als nur eine beliebige speicher-engine. sicherlich tun viele entwickler heute so, als wenn die datenbank ein notwendiges übel für ihre applikation ist und erstellen mal eben alles mit O/R.
Deshalb ist der einfachere Ansatz, die Datenzugriffslogik in der programmierten Applikation zu realisieren, und die Datenbank im Prinzip nur als Speicher zu benutzen
und genau das halte ich für ziemlich dumm. aber jede generation muss halt ihre erfahrungen machen.
Ilja
-
-
-
Hi!
Ich glaube, die Argumentation pro MySQLi ist auch prophylaktischer Natur. Es wäre blöd, wenn man sämtlichen Code mitten im Projekt umstellen muss, nur weil plötzlich ein Feature gebraucht wird, das nurmit mysqli funktioniert.
Dann muss man deiner Argumentation folgend ja nur einen Buchstaben hinzufügen. (ja, und die Link-Variable hinzufügen.)
Es gibt genau ein stichhaltiges Argument pro mysqli: Man kann damit mehr machen, als mit mysql, und es soll auch performanter sein, ansonsten verhält es sich genau gleich.
Die Performance kann nicht so gravierend unterschiedlich sein, dass das ins Gewicht fällt. Vielleicht war das früher mal so, aber seit dem Umbau dürfte es da keine relevanten Unterschiede geben. Die meiste Zeit am gesamten Prozess verbraucht immer noch das Abarbeiten der Query auf dem Server und die Kommunikation dorthin. Ich fand auch keine Aussagen, die eine Betrachtung unter Beachtung von mysqlnd vornimmt. Ich fand hingegen eine Aussage, dass mysql minimal schneller sei als mysqli und dass der Unterschied zu gering ist.
Und wenn mysql und mysqli funktional bei den Punkten, die beide abdecken, sich identisch verhalten, dann gewinnt die Variante, die mehr potentielle Möglichkeiten bietet und schneller ist. Und das ist mysqli.
Abgesehen von dem Geschwindigkeits"argument" ...
Das reicht mir als Grund für eine pauschale Empfehlung aus.
... bleiben wir uns in dem Punkt uneinig. Mehr Funktionalität, die ungenutzt bleibt, bei geringem Änderungsaufwand, falls man sie doch benötigt, bleibt für mich nicht ausreichend.
Lo!
- Multiquerys?
-
-
-
-
-
-