Problem z obiektami w zapytaniach MYSQL "Warning: mysql_fetch_object(): supplied argument..." - PHP
Farnell, An Avnet Company   Przedstawicielstwo Handlowe Paweł Rutkowski   Fluke Europe B.V.  

Energetyka, Automatyka przemysłowa, Elektrotechnika

Dodaj firmę Ogłoszenia Poleć znajomemu Dodaj artykuł Newsletter RSS
strona główna GRUPY PHP Problem z obiektami w zapytaniach MYSQL "Warning: mysql_fetch_object(): supplied argument..."
REKLAMA
Przejdź do grup
REKLAMA

Problem z obiektami w zapytaniach MYSQL "Warning: mysql_fetch_object(): supplied argument..."

Awatar użytkownika
AnnaTopczewska

Witam,

Zaczęłam stosowanie obiektowe odwoływanie się do wyników wyszukiwania mysql i otrzymują taki błąd:

Warning: mysql_fetch_object(): supplied argument is not a valid MySQL result resource in....

Myślałem, że to może przez to, że w zapytaniach SQL wpisywałam

...nazwa=$obiekt->wartosc...

poprawiłam to poprzez zmienną:

$obiektwartosc=$obiekt->wartosc;

i w zapytaniach mam teraz

...nazwa=$obiektwartosc...

I ciągle ten warning, skrypt jest wykonywany poprawnie ale drażni mnie to. Znacie może przyczynę takich ostrzeżeń?

cytuj pomógł zgłoś nadużycie
Brak awataru
Brak użytkownika

Jak rozumiem ciąg tworzący zapytanie a zawierający fragment:

...nazwa=$obiektwartosc...

jest zawarty w podwójnych cudzysłowach (") a zmienne są wyłącznie liczbowe i przeescapeowane?

Poprosimy o więcej kodu AS IS, oczywiście z wytartymi danymi dostępowymi dla bazy... :P bo coś czuję, że to o te nieszczęsne result się rozchodzi, brakujące ciapki w query stringu albo inszą inszość (krótko mówiąc: coś po drodze a błąd dopiero wywala się na fetch-owaniu).

Ale! Jak będzie kod - popatrzymy, podyskutujemy, poradzimy... :)

 

EDIT:

Jeśli zapytanie jest opakowane w podwójne ciapki to można obejść się bez pośrednich podstawień korzystając tylko z nawiasów klamrowych `{` oraz `}`. Co jednak nie zwalnia przed walidowaniem lub/i escapeowaniem danych!

Przykład:

$query = "SELECT `id`, `uid`, `key` FROM pending_jobs WHERE `state`='{$request->state}' AND errors=0";

(proszę przekopiować powyższe zapytanie do jakiegoś notatnika i dokładnie przyjrzeć się występującym tam apostrofom - są ich aż trzy rodzaje!)

Odwrotny apostrof (zwykle umieszczony na klawiaturze z tzw. tyldą (~), obok cyfry jeden) daje możliwość operowania na polach bazy, gdy ich nazwy są częścią składni języka SQL (np. KEY) - zwykle nie trzeba ich używać ale...przezorny zawsze ubezpieczony.

Pojedynczy (prosty) apostrof (zwany czasami pojedynczym ciapkiem) służy zwykle do otaczania wartości, które są ciągami. W MySQL-u liczby też można otaczać ciapkami - dla silnika bazy to zwykle bez znaczenia - on i tak to sobie jeszcze z raz wszystko przetwarza.

Podwójny (prosty! w odróżnieniu do pisarskich) apostrof (zwany czasami podwójnym ciapkiem lub quotem) może także otaczać wartości ale jeśli całe query jest zawarte w takich samych ciapkach - to te wewnątrz trzeba wyeskejpować ("... WHERE state=\"stalled\" ..." - to jest przykład z podwójnymi, z pojedynczymi jest tak samo tyle że pojedyncze ciapki utrzymujące całe zapytanie nie pozwalają na osadzanie w nim zmiennych poprzez dolary i klamerki).

cytuj pomógł zgłoś nadużycie
Awatar użytkownika
AnnaTopczewska

zauważyłam jedną rzecz, że w jednym miejscu błąd wynikał z literówki w zmiennej ale błędy dalej są - zweryfikuję wszystkie nazwy i ewentualnie podam treść skryptu.

btw. Dzięki za szybką odpowiedź.

cytuj pomógł zgłoś nadużycie
Awatar użytkownika
AnnaTopczewska

Witam ponownie,

sprawdziłam cały skrypt od A do Z i według mnie ZERO błędu składni.

Przyszło mi jeszcze do głowy wyświetlić wartość komórki w bazie przy której następował błąd. Wzięło się to stąd, że jakby był błąd kodu to miałabym błąd przy każdorazowym przejściu pętli wybierającej wartości a do myślenia mi dało to, że zamiast około 80000 ostrzeżeń miałam 2.

Wartością zwracaną jako wynik zapytania okazał się być : NULL

i przez to całe zamieszanie,

dla czytelników dodam, żę moje zapytania wyglądają tak:

$zap4a = "select `kolumna1`,`kolumna2` from `[nazwa tablicy]` WHERE `pole1`=$obiekt->id order by `[nazwa]` asc Limit 1";

Nie stosuję '{$request->state}' bo w podwójnych cudzysłowach przyjmuje zarówno wartości przekazywane jako zmienne np $wartość

$zap4a = "select * from `[nazwa tablicy]` WHERE `pole1`=$zmienna";

jak i obiekty:

$zap4a = "select * from `[nazwa tablicy]` WHERE `pole1`=$obiekt->zmienna";

a jeśli przyjmuje to pomijam (skrypt waży mniej, nie wielie mnie j ale jeśli jest wykonywany 50-100tys razy to może być odczuwalny

 

cytuj pomógł zgłoś nadużycie
Brak awataru
Brak użytkownika

PHP jest dość elastyczny jeśli chodzi o składnię - to fakt...

Co do optymalizacji (tak trochę offtopowo): jeśli co N minut ciągi zawierające zapytania są parsowane i takich parsowań (a więc i zapytań) w jednym odpaleniu skryptu jest kilkadziesiąt czy kilkaset tysięcy to zdecydowanie bardziej opłaca się zoptymalizować algorytm działania procedur (przy konieczności obróbki większej ilości danych ze zdalnej maszyny, np. idących w setki tysięcy czy miliony rekordów lepsze jest zbieranie paczkami, przetwarzanie w skrypcie, nawet trochę większym kosztem pamięci i procka). Nie należy próbować usilnie walczyć z przetwarzaniem kodu przez interpreter bo to będą mikrooptymalizacje (fakt - w tej ilości będą nawet może i mierzalne) ale nie tędy droga :)

cytuj pomógł zgłoś nadużycie
Awatar użytkownika
AnnaTopczewska

Dziękuję jeszcze raz za wszystkie wskazówki. Mam zamiar się podszkolić (czyt. spróbuję zastosować).

Pozdrawiam

cytuj pomógł zgłoś nadużycie
odpowiedz
REKLAMA
Nasze serwisy:
elektrykapradnietyka.com
przegladelektryczny.pl
rynekelektroniki.pl
automatykairobotyka.pl
budowainfo.pl