XAMPP Wyrzuca mi na stronie:
Fatal error: Uncaught mysqli_sql_exception: Access denied for user 'gabor'@'localhost' (using password: YES)
in C:\xampp\htdocs\tmp\index.php:8
Stack trace:
#0 C:\xampp\htdocs\tmp\index.php(8): mysqli->__construct('localhost', 'gabor', Object(SensitiveParameterValue), 'gabor')
#1 {main} thrown in C:\xampp\htdocs\tmp\index.php on line 8'.
oczywiście w linii 8 mam:
$con = new mysqli(...);
Proszę! Jak mam się połączyć?
Na pewno masz prawidłowo podanego użytkownika, hasło i bazę?
Sprawdź sobie w XAMPP i ustaw ewentulanie nowe: https://kinsta.com/knowledgebase/xampp-mysql-password/
Tak BTW.
Nie ucz się już i nie pisz połączeń przy użyciu mysqli w dzisiejszych czasach trzeba używać już PDO: https://www.php.net/manual/en/book.pdo.php
gaborek1987 napisał(a):
Proszę! Jak mam się połączyć?
nadać użytkownikowi gabor odpowiednie uprawnienia w bazie
Riddle napisał(a):
Nie polecam używać
mysqli. Dużo lepiej użyć PDO.
PDO to prawodpodobnie najlepszy wybór, ale....
W niektórych przypadkach natywny driver jest konieczny, np. kiedy trzeba skorzystać w SQL z niestandardowych poleceń - np. z natywnej składni dla JSONa w PostgreSQL której nie da się wykorzystać w aktualnym PDO: znak ? jest w PDO placeholderem, a w PostgreSQL jest jedną z funkcji do operowania na json/jsonb.
TomRZ napisał(a):
W niektórych przypadkach natywny driver jest konieczny, np. kiedy trzeba skorzystać w SQL z niestandardowych poleceń - np. z natywnej składni dla JSONa w PostgreSQL której nie da się wykorzystać w aktualnym PDO: znak ? jest w PDO placeholderem, a w PostgreSQL jest jedną z funkcji do operowania na json/jsonb.
Zajęło mi 2 sekundy żeby znaleźć ten link w google po wpisaniu "pdo postgres json placeholder".
Poza tym, myślisz że na prawdę Twórcy PDO nie wzięliby pod uwagę przypadku że ktoś chce użyć znaku ? w zapytaniu? No szanujmy się.
Niestety ale to jest złe rozwiązanie. Co więcej w samym PostgreSQL istnieją odpowiedniki funkcji ?, które można zapisać tak, że będą zgodne ze standardem SQL i można korzystać z PDO.
Niestety, zastępowanie natywnej funkcji ? (i innych tego typu) jakimkolwiek obejściem - tym które wymieniłem lub własnym jak na stacku, skutkuje tym, że PostgreSQL nie radzi sobie z optymalizacją - nie korzysta w Plannerze np. z indeksów JSONowych.
Dlatego szybka odpowiedź ze stacka znaleziona w 5 sekund nie jest prawidłowym rozwiązaniem, na dzień dzisiejszy, dopóki PostgreSQL tego nie zoptymalizuje - ja jestem zmuszony korzystać z natywnego (w kilku miejscach, reszta PDO).
TomRZ napisał(a):
Niestety ale to jest złe rozwiązanie. Co więcej w samym PostgreSQL istnieją odpowiedniki funkcji ?, które można zapisać tak, że będą zgodne ze standardem SQL i można korzystać z PDO.
Niestety, zastępowanie natywnej funkcji ? (i innych tego typu) jakimkolwiek obejściem - tym które wymieniłem lub własnym jak na stacku, skutkuje tym, że PostgreSQL nie radzi sobie z optymalizacją - nie korzysta w Plannerze np. z indeksów JSONowych.
A przeczytałeś cały wątek? Zobacz na tą odpowiedź: https://stackoverflow.com/a/69775182/3429015
Użycie podwójnego ?? w PDO yielduje natywne ?.
PDO to jedno, ale niestety ORM to drugie - nie podoba się ORMowi podwójny ??, jeżeli miałbym to całkowicie integrować z zasadami systemu to powinno być na ORM, samo PDO mi nic nie daję, jest takim samym wyjątkiem jak natywny driver, a natywny driver pewnie odrobinę szybciej działa. I robiąc to kapnąłem się, że już to wcześniej przerabiałem, tylko zapomniałem - za dużo projektów na głowie.
TomRZ napisał(a):
PDO to jedno, ale niestety ORM to drugie - nie podoba się ORMowi podwójny ??, jeżeli miałbym to całkowicie integrować z zasadami systemu to powinno być na ORM, samo PDO mi nic nie daję, jest takim samym wyjątkiem jak natywny driver, a natywny driver pewnie odrobinę szybciej działa. I robiąc to kapnąłem się, że już to wcześniej przerabiałem, tylko zapomniałem - za dużo projektów na głowie.
Tak, PDO to nie jest ORM, to jest po prostu biblioteka/driver do połączenia z bazą danych, i ma wiele przewag na mysqli_.
