Forum PHP.pl

Ze średnikami działa w kreatorze (widoku projektu kwerendy), z przecinkami w SQL.

[PHP] pobierz, plaintext 
$q3 = "SELECT COUNT(*) AS wynik FROM metryczka WHERE wyksztalcenie = 'Podstawowe'";
[PHP] pobierz, plaintext 

[SQL] pobierz, plaintext 
SELECT t.id_towar, t.nazwa, f.data_zak
FROM towar t
LEFT  JOIN  (faktura f,  faktura_has_towar thf) /* nie wiem WTF ale tak zostawię */
ON (t.id_towar=thf.id_towar AND f.id_faktura=thf.id_faktura )
 
WHERE 
  t.nazwa LIKE '%jakaś niepełna nazwa towaru%' 
  AND (t.id_towar,f.data_zak) IN (SELECT t.id_towar, MAX(f.data_zak) FROM towar t JOIN  (faktura f,  faktura_has_towar thf) ON (t.id_towar=thf.id_towar AND f.id_faktura=thf.id_faktura ) GROUP BY 1) 
ORDER BY t.nazwa, f.data_zak ASC
[SQL] pobierz, plaintext 

Co do Warningów, to powinieneś używać mysqli_query, tyak jak masz w baza_portal_artyk.php w np. linii 20:

[PHP] pobierz, plaintext 
$wynik= mysqli_query($polaczenie, "SELECT * FROM 'artykuly'");
[PHP] pobierz, plaintext 

Czyli jako pierwszy parametr dajesz połączenie do bazy. Inaczej domyślnie PHP weźmie ostatnio utworzone.

Co do błędu w linii 125, to wydaje mi się, że powinno być:

[PHP] pobierz, plaintext 
$artykuly=mysqli_fetch_assoc($wynik1);
[PHP] pobierz, plaintext 

Tak samo jakbyś dodał TAG. Rozwiązań mnóstwo w necie.

Stawiam na jakąś nietypową kontrolkę ActiveX, której nie ma na komputerze docelowym. Sprawdż w referencjach, gdzie masz "missing"

Jeśli założysz indeks, to dodawanie kolejnych nowych rekordów (a także UPDATE kolumn z indeksów) będzie trwało dłużej. Związane jest to z tym, że za każdym razem "odbudowywany" jest indeks.
Indeks przyspiesza odczyt danych, ale zwalnia ich zapis.

Pokazałem Ci, że da się zrobić tabelę z PK z dwóch pól, z których jedno jest autoincrement. I na dodatek Engine InnoDB.

Czary: http://sqlfiddle.com/#!9/f82f1f/2

Nie będzie lekko. Jeśli masz zrobiony BACKUP z MS SQL Server. to musisz zainstalować sobie SQL Server i odtworzyć backup żeby się do tych danych dostać. A i to czasme się nie udaje... Jeśli np. nie będziesz miał odpowiednich użytkowników, to się nie dostaniesz

1 INSERT a potem 5 UPDATE

ORDER BY CASE WHEN status='ODŁOŻONE' THEN 1 ELSE 0 END

A nie powinno być tak:?

[SQL] pobierz, plaintext 
SELECT (SELECT count(s) FROM RequestEvent re WHERE re.server = s) + (SELECT count(se) FROM SqlEvent se WHERE se.server = s)
[SQL] pobierz, plaintext 

http://sqlfiddle.com/#!9/079e99/2
?

[SQL] pobierz, plaintext 
SELECT z.id_zamowienia FROM zamowienia z JOIN statusy_historia s ON s.id_zamowienia=z.id_zamowienia AND s.nazwa IN ('AAA', 'BBB', 'XXX')
GROUP BY 1
HAVING count(DISTINCT s.nazwa)>Count(DISTINCT CASE WHEN s.nazwa='xxx' THEN s.nazwa END)
[SQL] pobierz, plaintext 

Count(status) policzy rekordy z nieNULLową kolumną status. Count(*)-Count(status) policzy rekordy z NULLową kolumną status

Nie masz grupować po kraju.

[SQL] pobierz, plaintext 
SELECT year(data_ur) AS rokUrodzenia, quarter(data_ur) AS kwartal, count(*) FROM zawodnicy  GROUP BY 1,2
[SQL] pobierz, plaintext 

[SQL] pobierz, plaintext 
WHERE airports_list.id  IS NULL
[SQL] pobierz, plaintext 

http://sqlfiddle.com/#!9/f9357f/6

Wytłumaczę ci najprościej jak się da. Baza danych porównuje zbiory. Zbiór twoich danych wejściowych (daną wejściową jest rekord) ze zbiorem danych z tabeli.
Utwórz sobie taki zbiór i go go porównaj z tabelą. Jesli go nie znajdzie, to wtedy dodaj.
Czyli po kolei
Utworzenie zbioru jednoelementowego:

[SQL] pobierz, plaintext 
SELECT :login AS login, :mail AS mail, :password AS pass, :ip AS ip, :DATA AS date
[SQL] pobierz, plaintext 

Teraz sprawdzasz, czy danych zbiór istnieje. Warunkiem istnienia jest klucz, czyli w tym przypadku login. Jak najłatwiej sprawdzić? Połączyć lewostronnie po kluczu i sprawdzić, czy w drugiej tabeli znalazł dany rekord.

[SQL] pobierz, plaintext 
SELECT * FROM
(SELECT :login AS login, :mail AS mail, :password AS pass, :ip AS ip, :DATA AS date) AS sub
LEFT JOIN 
users AS u
ON u.login=sub.login
WHERE 
u.login IS NULL
[SQL] pobierz, plaintext 

Jeśli zapytanie zwróci ci jakikolwiek rekord (a może zwrócić tylko jeden), to wtedy dodajesz go do `users`. Zapytanie jest o tyle bezpieczne, że możesz je wykonywać ile razy chcesz - rekord doda się tylko raz (bo za każdą następną próbą już będzie)

[SQL] pobierz, plaintext 
INSERT INTO users(login, mail, pass, ip, date)
SELECT sub.* FROM
(SELECT :login AS login, :mail AS mail, :password AS pass, :ip AS ip, :DATA AS date) AS sub
LEFT JOIN 
users AS u
ON u.login=sub.login
WHERE 
u.login IS NULL
[SQL] pobierz, plaintext 

Źle rozumiesz. Jeśli jest typ kolumny NUMBER, to ani w OLD, anie w NEW nie ma prawa znaleźć się 'a'.

Kolumna TYP_WEZLA oczywiście może być NUMBER, ale musiałbyś zmienić wprowadzanie danych.

[SQL] pobierz, plaintext 
IF :NEW.TYP_WEZLA LIKE 'a' THEN :NEW.TYP_WEZLA := 1; END IF;
[SQL] pobierz, plaintext 

Jak widać, wprowadzasz do rekrodu (przed zapisem) dane typu 'a', 'b'..., a baza działa tak, że najpierw jest tworzony obiekt "old" i "new" takiego samego typu jak trrekored danej tabeli. Do "old" pobierane są wartości aktualne, a do "new", te które chcesz wpisać. I właśnie do "new" do pola NUMBER nie możesz wpisać 'a'. To nie jest błąd triggera, bo to się dzieje zanim jeszcze trigger zacznie działać...

Bo się nie da...
Albo unikalne maile, albo unikalne pary (mail, id).
Możesz zrobić pobieranie ostatniego/pierwszego z danym mail.
Przy założeniu, że id jest unikalne i rosnące, to

[SQL] pobierz, plaintext 
SELECT mail, min(id) min_id, max(id) max_id FROM post GROUP BY mail
[SQL] pobierz, plaintext 

Liczby przy INT mają sens tylko w przypadku użycia ZEROFILL.
INT signed i unsigned zajmują tyle samo miejsca w pamięci, ale mają różny zakres wartości. Cytując dokumentację;
INT[(M)] [UNSIGNED] [ZEROFILL]

A normal-size integer. The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.


Ma sens. Jeśli na 99% rekordów jakieś pole ma wartość 0, to po prostu nie ustawiasz tej wartości przy zapisie. DLa tego 1% zmieniasz (przed lub po zapisie) na inną wartoiść


Jakie "zwykłe klucze KEY"? Chodzi ci o indeksy?


Nie. Bo wtedy dopuszczałbyś sytuację z dwoma takimi samymi loginami, ale różnymi hasłami.


Zależy od wielu czynników. Generalnie SELECT odbywa się szybciej. INSERT i UPDATE jest wolniejszy, bo wymaga przebudowania indeksów.