PEAR::DB, sqlite_query() expects parameter 1 to be resource

ve.ru · 11.02.2005, 16:18

Hallo,

ich habe ein Probelm bei Datenbankzugriff über PEAR::DB in Zusammenhang mit Sessions:

vereinfacht passiert folgendes:

Code:

class A {
  private $_db;
  
  function __construct (&db) {
    $this->_db = $db;
  }

  function getAll() {
    echo get_class($this->_db);
    $SQL=...;
    $result =& $this->_db->getAssoc($SQL);
    ....
  }

  function ohneDB() {
    print "das klappt";
  }

}

Diese Klasse wird in etwa so verwendet:

Code:

if (!isset($_SESSION['a'])) {
  $db =& DB::connect($dsn, $options);
  $a = new A($db);
  $_SESSION['a'] = $a;
}

$_SESSION['a']->ohneDB();
$_SESSION['a']->getAll();

Beim ersten Aufruf dieser Seite klappt alles. Beim zweiten Aufruf wird die Methode ohneDB noch korrekt ausgeführt, die Methode getAll gibt zuerst als Klasse von $_db korrekt ein "DB_sqlite" aus und bringt dann den Fehler:

Code:

 ** SELECT * FROM ab_addresses [nativecode=sqlite_query() expects parameter 1 to be resource, string given]

Die Datenbank ist eine SQLite Datei, ich verwende PHP 5.0.3 unter Linux, xitami Webserver.

Die notwendigen Klassendateien werden eingebunden, bevor ich session_start() aufrufe und session_auto_start ist deaktiviert.

Hat jemand einen Hinweis für mich?

Danke,
Verena

robo47 · 11.02.2005, 17:10

die reihenfolge ist umgekehrt wie bei mysql_query zum beispiel, erst die resource dann das query, wie wärs wenn du die zeile die du hier $SQL=...; rausgenommen hast einfach mal zeigst?

ve.ru · 11.02.2005, 17:25

Die Orginalmethode:

Code:

	function getAddresses($condition, $limit) {
		$SQL = "SELECT * FROM {$this->_tabPrefix}addresses";
		if ($condition != "" ) {
			$SQL .= " WHERE $condition";
		}
		if ($limit != "") {
			$SQL .= " LIMIT {$limit['from']},{$limit['to']}";
		}
		$result =& $this->_db->getAssoc($SQL);
		if (DB::isError($result))  {
			echo "<pre>";
			//print_r($this->_db);
			echo get_class($this->_db);
			echo "</pre>";
			die("
Fehler   
".$result->getUserInfo()); 
		}
		return $result;
	} // end function getAddresses

Ich rufe aber sqlite_query nicht direkt auf, sondern nutze PEAR:

B als Abstraktionslayer. Und die PEAR Methode query nimmt nur einen Parameter, nämlich den SQL String entgegen.

Ich bin nun etwas weiter, indem ich die PEAR Klasse auseinander genommen habe. Dort ist an entsprechender Stelle folgende Zeile:

Code:

$result = sqlite_query($query, $this->connection);

Ab dem zweiten Aufruf ist $this->connection NULL, das Datenbankobjekt vergisst also seine Verbindung zur Datenbank nach dem Wiederherstellen der Session???

Grüße,
Verena

11.02.2005, 17:31

Zitat:

Zitat von ve.ru

Hat jemand einen Hinweis für mich?

Das beachtet?

29.13. Wie speichere ich Objekte in Sessions?
http://www.php-faq.de/q/q-sessions-objekte.html

robo47 · 11.02.2005, 17:32

$result = sqlite_query($query, $this->connection); ist definitiv falsch, änder das mal in

$result = sqlite_query($this->connection, $query);

und schau ob es funktioniert, weil die fehlermeldung sagt, dass sie die reource will und dann das query. würde mich wundern wenn das in ner pear-klasse falsch drinsteht.

11.02.2005, 17:48

Zitat:

Zitat von robo47

$result = sqlite_query($query, $this->connection); ist definitiv falsch, änder das mal in

$result = sqlite_query($this->connection, $query);

Das schon gesehen?

Zitat:

Zitat von Handbuch

resource sqlite_query ( resource db, string Abfrage)
resource sqlite_query ( string Abfrage, resource db)

ve.ru · 11.02.2005, 18:01

@meikel:
ja und nein.
Ich hatte es mir schon angeschaut, aber ich möchte die Verbindung zur Datenbank nicht bei jedem Seitenaufruf schließen und wieder neu öffnen. Beim Erstellen des PEAR:

B Objekts gebe ich an, das es eine persistente Verbindung sein soll. Dann würde es doch keinen Sinn machen, diese jedesmal zu schließen und neu zu öffnen. Oder habe ich das was grundsätzlicheres falsch verstanden?
Das eigentliche Datenbank-Objekt wird auch wieder richtig hergestellt (lt. der Ausgabe von get_class($this->_db)), aber das darin enthaltene Connection-Objekt nicht.

@robo47:
Das steht da allen Ernstes. Ist auch die aktuelle Version. Aber nu wirds noch komischer: vertausche ich die beiden Parameter wie Du gemeint hast, passiert genau das gleiche! sqlite_query überprüft anscheinend, was ein String und was ein Objekt ist und handelt entsprechend.

Grüße,
Verena

11.02.2005, 18:14

Zitat:

Zitat von ve.ru

@meikel:
ja und nein.
Ich hatte es mir schon angeschaut, aber ich möchte die Verbindung zur Datenbank nicht bei jedem Seitenaufruf schließen und wieder neu öffnen. Beim Erstellen des PEAR:

B Objekts gebe ich an, das es eine persistente Verbindung sein soll. Dann würde es doch keinen Sinn machen, diese jedesmal zu schließen und neu zu öffnen. Oder habe ich das was grundsätzlicheres falsch verstanden?

Wahrscheinlich. PHP-SQLite ist kein DBMS, das standalone im Speicher hängt, sondern eine schlichte PHP Extension, die Dein Datenbankfile öffnet und das Query ausführt. Da ist eine 'persistente' Verbindung echt sinnfrei.

Zitat:

Das eigentliche Datenbank-Objekt wird auch wieder richtig hergestellt (lt. der Ausgabe von get_class($this->_db)), aber das darin enthaltene Connection-Objekt nicht.

Warum so umständlich? Bei einer filebasierten Datenbank wie SQLite, die noch dazu ohne Authentifizierung angesprochen wird, bringt das Halten der Verbindung absolut keine Punkte

Mach Dir lieber Gedanken darüber, was passiert, wenn auf diese Datenbank zeitgleich mehr als ein Schreibzugriff stattfindet.

ve.ru · 11.02.2005, 18:26

Warum gibt es dann die zwei Funktionen sqlite_open und sqlite_popen? Ich hatte mir einen Geschwindigkeitsvorteil erwartet, wenn die Verbindung nicht immer wieder hergestellt werden muss. Mir ist schon klar, dass da kein Server läuft, aber beim connect werden doch wahrscheinlich auch irgendwelche Überprüfungen ausgeführt (existiert das File, Berechtigung, ...) die ich mir dann ersparen wollte.
Außerdem ist es dann unsinnig, PEAR:

B mit SQLite zu verwenden, wenn das nicht geht. Würde ich morgen SQLite gegen Postgres austauschen wollen, wäre es wohl ein Unterschied ob persistente Verbindung oder nicht und der Code sollte dann ja (im wesentlichen) nicht mehr geändert werden müssen (so habe ich zumindest den Zweck von PEAR:

B verstanden).

11.02.2005, 18:38

Zitat:

Zitat von ve.ru

Warum gibt es dann die zwei Funktionen sqlite_open und sqlite_popen?

Weil es auch sinnlose Funktionen geben muß.

Zitat:

Mir ist schon klar, dass da kein Server läuft, aber beim connect werden doch wahrscheinlich auch irgendwelche Überprüfungen ausgeführt (existiert das File, Berechtigung, ...) die ich mir dann ersparen wollte.

Naja, Linux guckt nach, ob PHP das File öffnen darf. Das wars aber auch schon...

Zitat:

Würde ich morgen SQLite gegen Postgres austauschen wollen, wäre es wohl ein Unterschied ob persistente Verbindung oder nicht und der Code sollte dann ja (im wesentlichen) nicht mehr geändert werden müssen (so habe ich zumindest den Zweck von PEAR:

B verstanden).

So isser zwar gedacht, aber es ist schlicht und einfach nur ein schönes Märchen, es gäbe serverunabhängiges SQL. Wer schon mal mit PL/SQL UND TransactSQL gearbeitet hat, der weiß, daß er seine Oracle Abfragen nicht ohne Korrektur MSSQL anbieten kann UND umgekehrt.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] PHP -> Ordner anlegen der sich auch beschreiben lässt?!	Nightuser	PHP Tipps 2008	13	30.06.2008 23:51
Parameter überschreiben	Igäl	PHP Tipps 2006	8	04.06.2006 19:55
Suche Tipps für Persormance-Steigerung (Geld für Nützliches)		Beitragsarchiv	18	16.08.2005 10:57
ShowIt_V1.8.14		PHP Tipps 2005	1	23.03.2005 19:13
frage zum arbeiten mit dateien		PHP Tipps 2005	21	01.03.2005 13:22

11.02.2005, 16:18
ve.ru Benutzer Registriert seit: 11.02.2005 Beiträge: 30	PEAR::DB, sqlite_query() expects parameter 1 to be resource Hallo, ich habe ein Probelm bei Datenbankzugriff über PEAR::DB in Zusammenhang mit Sessions: vereinfacht passiert folgendes: Code: class A { private $_db; function __construct (&db) { $this->_db = $db; } function getAll() { echo get_class($this->_db); $SQL=...; $result =& $this->_db->getAssoc($SQL); .... } function ohneDB() { print "das klappt"; } } Diese Klasse wird in etwa so verwendet: Code: if (!isset($_SESSION['a'])) { $db =& DB::connect($dsn, $options); $a = new A($db); $_SESSION['a'] = $a; } $_SESSION['a']->ohneDB(); $_SESSION['a']->getAll(); Beim ersten Aufruf dieser Seite klappt alles. Beim zweiten Aufruf wird die Methode ohneDB noch korrekt ausgeführt, die Methode getAll gibt zuerst als Klasse von $_db korrekt ein "DB_sqlite" aus und bringt dann den Fehler: Code: ** SELECT * FROM ab_addresses [nativecode=sqlite_query() expects parameter 1 to be resource, string given] Die Datenbank ist eine SQLite Datei, ich verwende PHP 5.0.3 unter Linux, xitami Webserver. Die notwendigen Klassendateien werden eingebunden, bevor ich session_start() aufrufe und session_auto_start ist deaktiviert. Hat jemand einen Hinweis für mich? Danke, Verena


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

11.02.2005, 17:10
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.792 PHP-Kenntnisse: Fortgeschritten	die reihenfolge ist umgekehrt wie bei mysql_query zum beispiel, erst die resource dann das query, wie wärs wenn du die zeile die du hier $SQL=...; rausgenommen hast einfach mal zeigst? __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework

11.02.2005, 17:25
ve.ru Benutzer Registriert seit: 11.02.2005 Beiträge: 30	Die Orginalmethode: Code: function getAddresses($condition, $limit) { $SQL = "SELECT * FROM {$this->_tabPrefix}addresses"; if ($condition != "" ) { $SQL .= " WHERE $condition"; } if ($limit != "") { $SQL .= " LIMIT {$limit['from']},{$limit['to']}"; } $result =& $this->_db->getAssoc($SQL); if (DB::isError($result)) { echo "<pre>"; //print_r($this->_db); echo get_class($this->_db); echo "</pre>"; die(" Fehler ".$result->getUserInfo()); } return $result; } // end function getAddresses Ich rufe aber sqlite_query nicht direkt auf, sondern nutze PEAR:B als Abstraktionslayer. Und die PEAR Methode query nimmt nur einen Parameter, nämlich den SQL String entgegen. Ich bin nun etwas weiter, indem ich die PEAR Klasse auseinander genommen habe. Dort ist an entsprechender Stelle folgende Zeile: Code: $result = sqlite_query($query, $this->connection); Ab dem zweiten Aufruf ist $this->connection NULL, das Datenbankobjekt vergisst also seine Verbindung zur Datenbank nach dem Wiederherstellen der Session??? Grüße, Verena

11.02.2005, 17:32
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.792 PHP-Kenntnisse: Fortgeschritten	$result = sqlite_query($query, $this->connection); ist definitiv falsch, änder das mal in $result = sqlite_query($this->connection, $query); und schau ob es funktioniert, weil die fehlermeldung sagt, dass sie die reource will und dann das query. würde mich wundern wenn das in ner pear-klasse falsch drinsteht. __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework

11.02.2005, 18:01
ve.ru Benutzer Registriert seit: 11.02.2005 Beiträge: 30	@meikel: ja und nein. Ich hatte es mir schon angeschaut, aber ich möchte die Verbindung zur Datenbank nicht bei jedem Seitenaufruf schließen und wieder neu öffnen. Beim Erstellen des PEAR:B Objekts gebe ich an, das es eine persistente Verbindung sein soll. Dann würde es doch keinen Sinn machen, diese jedesmal zu schließen und neu zu öffnen. Oder habe ich das was grundsätzlicheres falsch verstanden? Das eigentliche Datenbank-Objekt wird auch wieder richtig hergestellt (lt. der Ausgabe von get_class($this->_db)), aber das darin enthaltene Connection-Objekt nicht. @robo47: Das steht da allen Ernstes. Ist auch die aktuelle Version. Aber nu wirds noch komischer: vertausche ich die beiden Parameter wie Du gemeint hast, passiert genau das gleiche! sqlite_query überprüft anscheinend, was ein String und was ein Objekt ist und handelt entsprechend. Grüße, Verena

11.02.2005, 18:26
ve.ru Benutzer Registriert seit: 11.02.2005 Beiträge: 30	Warum gibt es dann die zwei Funktionen sqlite_open und sqlite_popen? Ich hatte mir einen Geschwindigkeitsvorteil erwartet, wenn die Verbindung nicht immer wieder hergestellt werden muss. Mir ist schon klar, dass da kein Server läuft, aber beim connect werden doch wahrscheinlich auch irgendwelche Überprüfungen ausgeführt (existiert das File, Berechtigung, ...) die ich mir dann ersparen wollte. Außerdem ist es dann unsinnig, PEAR:B mit SQLite zu verwenden, wenn das nicht geht. Würde ich morgen SQLite gegen Postgres austauschen wollen, wäre es wohl ein Unterschied ob persistente Verbindung oder nicht und der Code sollte dann ja (im wesentlichen) nicht mehr geändert werden müssen (so habe ich zumindest den Zweck von PEAR:B verstanden).