Wiatm!
Za pomocą funkcji foreach, otrzymuję tablice (niewiem ilu elementową) i mam takie pytanko jak pobrać z bazy danych te wiersze w których $id jest równa wartością z tablicy?

Np. funkcja zwróci mi tablicę

[PHP] pobierz, plaintext 
Array(1,3,5,7,)
[PHP] pobierz, plaintext 

Więc chcępobrać z bazy wiersze w których

[PHP] pobierz, plaintext 
$id=1;
$id=3;
$id=5;
$id=7;
[PHP] pobierz, plaintext 

Jak ma poprawnie być zbudowana taka pentla?

Podmien sobie, co trzeba.

Coś mi to nie wychodzi!
Mam taki kodzik

[PHP] pobierz, plaintext 
$chks = array();
foreach($_GET as $k =>  $v) {
 
  if( substr( $k, 0, 4) == 'chk-'){
	$chks[]=$v;
	}
 
}
[PHP] pobierz, plaintext 

I teraz potrzebuję wstawić pętle, która zczytane wartości podstawi mi np. do

[PHP] pobierz, plaintext 
$tablica_wyników=Array(1,2,3,4);
[PHP] pobierz, plaintext 

Czy możesz na tym przykładzie pokazać jak ta pętla ma wyglądać?

Zainteresuj się

implode

i

MySql'owym

Dzięki za podpowiedź! Zrobiłem coś takiego:

[PHP] pobierz, plaintext 
$comma_separated = implode(",", $chks); 
$zapytanie = "SELECT `ph` FROM `analizys` WHERE `kj` IN ('$comma_separated')";
  echo mysql_error();
	$wykonaj = mysql_query ($zapytanie);
	while($wiersz=mysql_fetch_array ($wykonaj))
	{
	$ph=$wiersz['ph'];
	}
[PHP] pobierz, plaintext 

Funkcja

[PHP] pobierz, plaintext 
$comma_separated = implode(",", $chks); 
[PHP] pobierz, plaintext 

Zwraca mi np. cztery wartości a z bazy jest pobrana tylko pierwsza napotkana. Co robię źle? Czy błąd jest w pętli WHILE czy co? Proszę o pomoc.

nie:('$comma_separated')
a: ($comma_separated)

czemu wy zawsze bez namyslu rzucacie tymi ciapkami na lewo i prawo?

Już próbowałem!
Po tej zmianie zwraca mi ostatni rekord.

$ph=$wiersz['ph'];

no bo zakazdym obrotem petli nadpisujesz zmienną $ph

Witam!

Problem jest w implode oraz w zapytaniu:

1. Kiedy polaczyles implode'em tablice podales jako separator przecinek, czyli wynik:

1,2,3,4

i niby ok.

2. Ale w zapytaniu podstawiles zmienna, obejmujac ja ciapkami:
('$v_zmienna')

Czyli zapytanie przyjelo postac:

SELECT ... FROM .... WHERE `kj` IN ('1,2,3,4')

a wiec zamiast podac po przecinku kolejna wartosc dla IN'a , podales jeden string zawierajacy liczby po przecinku.

Jako ze MySQL jest mocno liberalny, obcial sobie pierwsza wartosc z listy (jedynke) i z niej skorzystal
(taki jego sposob na konwersje do liczby ;-)). Wiec dostales pierwszy wiersz z listy zamiast wszystkie cztery.

Inny system DB - np. Postgres krzyknal by Ci blad, ze podales napis tam gdzie sie spodziewa liczby (kolumna kj to integer) -i bylo by jasne - a mysql czasami przeholowuje z user friendly - ale to juz inna para kaloszy ;-)).

Rozwiazanie:

$comma_separated = implode("','", $chks);

- zwroc uwage na apostrofy przed i po przecinku. Czyli zapytanie przyjmie postac:

SELECT ... FROM .... WHERE `kj` IN ('1','2','3','4')

- i powinno byc ok ;-)

Podrawiam serdecznie,
Kacper

============================================
Szkolenia PHP, Warszawa

http://www.AplikacjeInternetowe.pl

Dzięki kchrapa. Po wstawieniu

[PHP] pobierz, plaintext 
$comma_separated = implode("','", $chks);
[PHP] pobierz, plaintext 

Daje mi coś taiego

[PHP] pobierz, plaintext 
SELECT ... FROM .... WHERE `kj` IN (1','2','3','4)
[PHP] pobierz, plaintext 

Więc jeszcze coś nie tak.

przeciez kchrapa napisal ci dokladnie to samo z tą roznicą, ze on mysli ze kod musi wygladac tak:
IN ('1','2','3','4')
a w cale nie musi tak wygladac. wystarczy ze bedzie tak:
IN (1,2,3,4)
czyli dokladnie to co ja ci napisalem. Na dodatek podal ci zly kod do generowanie swojego zamyslu...

Ok dzięki. Zczytuje mi wszystkie dane.

Witam!

Nospor:

Ehh,oczywiscie,ze nie musi byc w ciapkach (mam na mysli skladnie sql).Nie wiem skad pomysl, ze uwazam ze musi ...

Te ciapki nie sa z nadmiaru sily w palcach - tylko z przyzwyczajenia. Zabezpieczenie przed sql injection jesli nie korzystamy
z prepare/execute wymaga ich - oczywiscie w polaczeniu z mysql_real_escape_string/addslashes.
Mozna byloby zrezygnowac z tego i uzyc regexp'a wpuszczajacego tylko liczby calkowite - ale osobiscie wole to
ze soba polaczyc.

Wiec mysle, ze i ty rzucasz nimi (ciapkami) na lewo i prawo - chyba zgodzisz sie ze mna ;-)


Hmm - a tak z ciekawosci - w ktorym miejscu podalem zly kod? Patrze , patrze - i zdaje sie ze masz lepszy wzrok ode mnie...

Pozdrawiam serdecznie,
Kacper


============================================
Szkolenia PHP, Warszawa

http://www.AplikacjeInternetowe.pl

cos jest liczba, wiec nie daje tego w ciapki a ty do mnie tekstem ze ja ciapkami rzucam? Co piles?

No twoj kod wygenerowal:
IN (1','2','3','4)
nadal uwazasz ze to jest wlasciwy kod? Nie zapomniales o czyms?

Nie zapomnialem ;-)

Kod apkc oryginalnie wygladal tak ( post z 21:38 ):


$zapytanie = "SELECT `ph` FROM `analizys` WHERE `kj` IN ('$comma_separated')";

czyli zmienna $comma_separated byla objeta apostrofami.

Dla tej linijki podalem nowa wersja implode ;-)

Choc oczywiscie, mozna bylo obciac tez ciapki przy zmiennej, i jego poprzedni implode bez ciapkow by zadzialal - tak jak Ty napisales.

Zdaje sie, ze nasz kolega z rozpedu (pozno juz bylo ;-)) , zastosowal obie rady (moja i Twoja) - dodal apostrofy w implode
i obcial w stringu ;-) I odwrocil sytuacje ;-)Ale, moze sie myle - tutaj apkc musialby sie wypowiedziec ;-)

>> cos jest liczba, wiec nie daje tego w ciapki a ty do mnie tekstem ze ja ciapkami rzucam? Co piles? winksmiley.jpg
Nie w tym konkretnym wypadku. Mialem na mysli ogolnie komunikacje z baza ;-) A pilem... heh, herbate jak na razie ;-)

Pozdrawiam serdecznie,
Kacper


============================================
Szkolenia PHP, Warszawa

http://www.AplikacjeInternetowe.pl

Widze ze nadal nie wiesz gdzie zrobiles blad. Dobrze, wytlumacze ci to, bo widze ze robisz szkolenia wiec lepiej bys ludziom na szkoleniach tych bledow nie przekazał.
Twoj sposob:

[PHP] pobierz, plaintext 
$chks = array(1,2,3,4);
$comma_separated = implode("','", $chks);
echo $comma_separated;
[PHP] pobierz, plaintext 

Daje tekst: 1','2','3','4
brakuje apostrofa na początku i na koncu. Nalezy wiec twoj kod poprawic:

[PHP] pobierz, plaintext 
$chks = array(1,2,3,4);
$comma_separated = "'".implode("','", $chks)."'";
echo $comma_separated;
[PHP] pobierz, plaintext 

by uzyskac wlasciwy ciag: '1','2','3','4'

To ze ty tak robisz, nie znaczy ze inni tak robią. Gdy ja wkladam do bazy liczbe 5 to wkladam do bazy liczbe 5 a nie tekst '5'.

Nospor:

Czy przeczytales moj ostatni post ze zrozumieniem ?

>Kod apkc oryginalnie wygladal tak ( post z 21:38 ):
>$zapytanie = "SELECT `ph` FROM `analizys` WHERE `kj` IN ('$comma_separated')";
>czyli zmienna $comma_separated byla objeta apostrofami.
> Dla tej linijki podalem nowa wersja implode ;-)


Oczywiscie, ze jesli wykonasz po prostu echo na zmiennej to dostaniesz bez ciapkow zewnetrznych.
Ale apkc uzyl jej w konkretnym kontekscie - w zapytaniu SQL, gdzie zmienna BYLA OBJETA APOSTROFAMI !

Dla tego kontekstu podalem kod. I dlatego nie ma w nim bledu - bo apkc umiescil te apostrofy !
A pozniej - jak przypuszczam WYCIAL JE za Twoja rada ! Czytaj dokladnie, zanim zaczniesz krytykowac.


>To ze ty tak robisz, nie znaczy ze inni tak robią. Gdy ja wkladam do bazy liczbe 5 to wkladam do bazy liczbe 5 a nie >tekst '5'.

Proponuje abys zapoznal sie z dokumentacja php nt. danych wejsciowych - ktore sa stringiem , mimo
ze jest to liczba "z wygladu" - krotkie info jest chocby przy is_int() - http://php.net/manual/en/function.is-int.php .
Jesli dane pochodza z pliku - takze beda stringiem. Mozna je przepuszczac przez intval() , ale tez nie jest to
idealne rozwiazanie.

Nie sadze, aby apkc liste id mial wpisana z palca w skrypcie - jest to malo prawdpodobne, raczej pobieral je
z jakiegos wejscia - i jesli nie bylo to np. z bazy - to byly to stringi.

Poza tym , ufanie ze dane wejsciowe zawieraja liczby (czyli sa calkowicie bezpieczne), bo ty tak chcesz , jest naiwne i wprowadza dosc powazne zagrozenia. Wiec zanim bedziesz ludzi krytykowac za restrykcyjne walidowanie danych - zastanow sie glebiej. To ze Ty podchodzisz "lajtowo" do tematu , nie oznacza ze inni tak robia...





Pozdrawiam ,
Kacper

Tak, moj blad,przepraszam.

No ale w ktorym miejscu ja napisalem, ze dane wkladam do zapytania jak leci? Jesli to ma byc liczba, to albo ją waliduje albo rzutuje na liczbe i do zapytania wkladam liczbe a nie 'tekst'.

Chodzi o to, ze dobrze do zapytania jak cos jest liczbą to nalezy to wkladac jako liczbe a nie jako tekst. To uczy dobrych nawyków na później

A gdzie jak cie krytykowalem za walidacje danych? Ja cie krytykowalem za wkladanie liczb jako tekst

Conajmniej dziwne podejscie przepusczac liczbe przez mysql_escape_string. Liczb to liczba, zrzutuj na liczbe i nie bawisz sie w zadne escapowanie.

Panowie powoli!
Ja potrzebowałem pomocy, bo jestem zielony w te "klocki". Odpisaliście prawie jedocześnie na ten post więc już wogóle zgłupiałem i prawda prawdą, (chyba mniej świadomie) ale połączyłem wasze sugestie w jedną i dlatego wyszły mi takie bzdury. Jeszcze raz dziękuję Wam obu za pomoc.

>No ale w ktorym miejscu ja napisalem, ze dane wkladam do zapytania jak leci?

Masz racje - zbyt daleko idace przypuszczenie wysunalem ;-) Przepraszam.

> Jesli to ma byc liczba, to albo ją waliduje >albo rzutuje na liczbe i do zapytania wkladam liczbe a nie 'tekst'.
>A gdzie jak cie krytykowalem za walidacje danych? Ja cie krytykowalem za wkladanie liczb jako tekst

Z punktu widzenia DB nie ma to znaczenia - i tak serwer automatycznie dokona konwersji do typu danych kolumny.
Jesli mu sie nie uda - wyrzuci blad. Ale podkreslam ,ze i tak do tego nie dojdzie, bo na poziomie PHP nastapi
restrykcyjna walidacja (przy moim podejsciu) i zapytanie w ogole nie zostanie wyslane ;-)

Nie chce kruszyc kopii - obaj mamy po prostu troche rozne podejscia. Ja potencjalne liczby waliduje regexpem ,Ty
je rzutujesz.
I jak sadze - pewnie tez walidujesz - bo konwersja moze sie nie powiesc i funkcja (np. intval() lub inna) , moze zwrocic logiczny falsz - i w koncu po skonwertowaniu do int'a przez serwer DB wstawi sie wiersz z wartoscia 0 ;-) .

Masz - skadinad dobre - nawyki z innych jezykow ,ale to powoduje dwukrotna robote w tym kontekscie ;-) Nie oceniam, po prostu masz inne podejscie. Ja generalnie konwertuje tam, gdzie jest to niezbedne - jak np. w JS.

Pozdrawiam i dzieki wielkie za intensywna dyskusje ;-)
Kacper







>Conajmniej dziwne podejscie przepusczac liczbe przez mysql_escape_string. Liczb to liczba, zrzutuj na liczbe i nie bawisz >sie w zadne escapowanie.

No dobra, to teraz już na spokojnie:
napisz, jesli mozesz w ktorym miejscu ja robie podwójną robote a ty nie. Proszę na przykładach, by znowu nie było nieporozumień

Ależ proszę bardzo. Oboje sie cieszymy ze pomogliśmy, a teraz wyjasniamy jeszcze tylko kwestie sporne, które i tobie mogą sie przydac na przyszlosc

no nie moze. co najwyzej zwroci 0, gdy przepuszcze np. taki ciag "blabla". W niczym mi to nie przeszkadza. Oczekiwałem liczby i dostałem liczbe.

No wlasnie, ale z punktu widzenia DB MySQL. A jak sie przesiądzie na inną:

to bedzie ból bo nabrał złych nawyków, które ty propagujesz.

Moze nie podwojna - przesadzilem ;-) Ale dodatkowa czasami :-)

Wersja 1 - tylko walidacja.
<?php

// Walidacja
//tylko liczby calkowite
if (preg_match('/[^0-9]/',$_GET['ilosc'])){
echo 'Bledna ilosc';
exit();
}

//j.w.
if (preg_match('/[^0-9]/',$_GET['id_produktu'])){
echo 'Bledne id produktu';
exit();
}

//ciapki z przyzwyczajenia ;-)
$v_sql="UPDATE produkty SET ilosc='{$_GET['ilosc']}' WHERE id_produktu='{$_GET['id_produktu']}'";
$o_db->Execute($v_sql);


?>

w efekcie,jesli user poda cos co nie jest liczba calkowita (np . ilosc - 'xyz@cos', to program przerwie sie na etapie walidacji.
I ilosc produktu nie zostanie zmieniona.

Jesli jednak bysmy poprzestali np. na intval , bez walidacji,to moglibysmy zaktualizowac blednie dane:

Wersja 2 - samo intval
<?php

//nasza bledna dana (zyz@cos) zamieni sie na 0 - co przestawi ilosc produktu na zero
$_GET['ilosc']=intval($_GET['ilosc']);
$_GET['id_produktu']=intval($_GET['id_produktu']);

$v_sql="UPDATE produkty SET ilosc={$_GET['ilosc']} WHERE id_produktu={$_GET['id_produktu']}";
$o_db->Execute($v_sql);

?>

Wiec zeby uniknac powyzszego problemu, pewnie przed intval dodajesz podobna walidacje - czyli mamy i walidacje i konwersje ;-)
W sumie to nie tak duzo wiecej - a pewnie u ciebie rzutowanie jest we krwi jak u mnie ciapki ;-)wiec generalnie zaden problem
jak sie dobrze przyjrzec ;-)

Mysle - ze w tym przypadku i ciapki(u mnie) i intval( u ciebie) sa zbedne - ale co sila przyzwyczajenia to sila przyzwyczajenia ;-) :-)


Pozdrawiam,
Kacper

Widzisz, twoja walidacja sprawdza czy jest liczbą. Jak ktoś poda 0 to Twoja walidacja to przepusci i w efekcie dostaniesz 0 tak jak i ja robiac rzutowanie na tekscie. Widzisz jakąś roznice w efekcie koncowym?

Nie, nie robie walidacji. Ma byc liczbą wiec rzutuje na liczbe i po sprawie. Walidacja jest tylko wowczas, jesli liczba nie moze byc zerem albo liczbą spoza jakiegoś zakresu. Ale to i przy Twojej metodzie musialbym też dodac tę dodatkową walidacje, wiec nadal nie ma zadnego dodatkowego narzutu.

Niestety nadal uwazam ze rzutowanie na liczbe jest ok a dawanie ciapkow jest złym nawykiem.

Witaj nospor!

Wybacz za pozna odpowiedz, ale ostatnio mialem sporo pracy i nie mialem czasu odpowiedziec.

Kontynuujac bardzo ciekawa dyskusje :-)....



I. Cytat z wczesniejszego posta, w ktorym mnie zacytowales:-)




Chcialbym zauwazyc, ze te dwie moje wypowiedzi dotycza innych aspektow - polaczyles je w
jedno, wyrywajac z kontekstu.

I. Pierwsza wypowiedz ("Z punktu widzenia DB..")- chodzilo o automatyczne rzutowanie
POPRAWNYCH FORMALNIE LICZB (calkowitych i rzeczywistych) przez RDBMS. Jesli poprawna liczba
bedzie w ciapkach, zaden z systemow : MySQL, PostgreSQL, Oracle, MS SQL Server czy Firebird
nie bedzie mial najmniejszych problemow. Automatycznie dokona rzutowania i nawet sie
nie zajaknie(nie jestem pewien jak z DB2 - pracowalem w nim ostatnio z 10 lat temu...i nie pamietam,
ale pewnie podobnie).

Wiec nic nie zaboli przy przejsciu aplikacji na inny rdbms... ;-)
(a jesli sie pojawi problem - bedzie to jedynie kwestia zmiany w domyslnej konfiguracji).

II. Druga wypowiedz - wstawiles ja zeby potwierdzic ostatnie Twoje zdanie moimi slowami
("to bedzie bol..") - ale ona dotyczyla innego aspektu ;-)
Tutaj chodzilo mi o sytuacje , kiedy na wejscie trafia NIEPOPRAWNA LICZBA CALKOWITA
(np. podano liczbe z czescia dziesiatna).

MySQL domyslnie wykonuje liberalna konwersje, tracac czesc informacji (ucina po
przecinku/zaokragla), dosc liberalnie w przypadku klauzuli IN zachowuje sie tez Firebird i
Oracle.
Z kolei Postgres (wraz z MS SQL Server) , jesli bedzie w ciapkach - wyrzuci blad,
jesli bez ciapkow - przemilczy sprawe dokonujac specyficznej konwersji . Czyli raczej ciapki
wplywaja pozytywnie na zachowanie systemu, jako ze wywoluja blad nie pozwalajac
serwerowi wyrzucic nieadekwatnych danych.
Oczywiscie, powyzsze zachowanie podaje dla domyslnych ustawien tych rdbms'ow.

Reasumujac - w kontekscie zapytan SQL (bo tylko o tym byla mowa) - ujecie ich w ciapki wg
mojej wiedzy nie przynosi zadnych negatywnych konsekwencji,a biorac pod uwage
postgresa i mssqlserv - wrecz przeciwnie.

Aczkolwiek - jesli sa jakies obiektywne przyczyny (nie liczac przyzwyczajenia/gustu mojego
czy Twojego), o ktorych nie wiem a z powodu ktorych nalezy z ciapkow w SQL zrezygnowac -
bede wdzieczny za informacje :-)


Ustosunkuje sie jeszcze do ostatniej Twojej wypowiedzi :

Nospor:


I tutaj musze Ci jednak zwrocic uwage ,ze rzutowanie bez walidacji nie jest optymalnym podejsciem i moze
spowodowac konkretne problemy. Dlaczego?

To prawda, jesli uzytkownik przy zmianie ilosci produktu wpisze zero, i moj i Twoj program
to przepusci... bo oczywiscie zerowy stan produktow jest jak najbardziej sensowny.I moim
celem nie bylo uniemozliwienie ustawienia takiej wartosci.

Stosowanie walidacji w tym przypadku jest w innym celu - przechwycenie sytuacji,jesli user
nieswiadomie poda cos,co nie jest poprawna liczba calkowita w systemie dziesietnym (a nie
znam chyba usera, ktory SWIADOMIE bedzie probowal wpisac w tym miejscu zapis szesnastkowy
lub binarny - pomijam proby atakow).

I zwroc uwage na dwa podejscia do problemu :

A. z walidacja - system odrzuci jego żądanie informujac o bledzie.Czyli user od razu dowie
sie ze jest problem i swiadomie go skoryguje.

Sedno dzialania: Walidacja nie dopusci do przeklamania danych.

Potrzebna jest tu takze walidacja, aby system RDBMS tez nie dokonal niepoprawnego
rzutowania (np. zaokraglajac liczbe zmiennoprzecinkowa).


B. bez walidacji, ale z rzutowaniem - system skonwertuje bledna dana do 0
i zaktualizuje/wstawi produkt z niepoprawna iloscia.Bez jakiejkolwiek noty dla usera.
Dla jakich danych to nastapi ? Np.:
- 0x1B
- ania'
- x3444

Zarowno intval() jak i rzutowanie (int) liczba , zmodyfikuje bledne dane - zamiast
odrzucic, zmieni "cichaczem" na zero.

Pol biedy, jesli to robi user dla pojedynczego rekordu (moze zauwazy blad) -ale jesli importuje z csv
kilkaset tysiecy rekordow,program sie nawet nie zajaknie - a doswiadczenie pokazuje,
ze w duzej czesci systemow mamy smieci ( widzialem systemy (zarowno male, jak i miedzynarodowych korporacji) gdzie w polu numer_domu bylo wpisane "zosia" )) - podobnie w plikach csv od userow czy innych zrodlach danych.

Reasumujac - na tym poziomie widac bardzo istotna roznice w efekcie koncowym miedzy naszymi
rozwiazaniami.

Walidacja jest niezbedna nie tylko wtedy, gdy nie chcesz wpuscic zera itp, bo
jesli user wpisze 'gucio' , do bazy trafia calkowicie bledne dane (choc poprawne skladniowo
z uwagi na rzutowanie).

Mysle wiec, ze powinienes jednak rozwazyc wprowadzenie walidacji tam, gdzie
robisz tylko rzutowanie.Uszczelni ona system sprawiajac,ze bedzie mniej podatny na
umieszczanie w nim nieadekwatnych informacji.


Pozdrawiam serdecznie ,
Kacper

Ale mnie nie lubisz ze zmuszasz mnie do przeczytania takiej ilości tekstu...
Ustosunkuję się tylko do końcówki bo już po tak długiej przerwie odeszła mi ochota na tę zaciętą "kłótnie" . Mam nadzieję ze za bardzi się nie pogniewasz z tego powodu.

Problem w naszej dyskusji polega na tym, ze mówimy ogólnie albo w ramach sytuacji o której sami myślimy.
Ja mówiąc o rzutowaniu bez walidacji miałem na myśli sytuację, gdy user nie wprowadza danych tylko ma je podane i musi coś zaznaczyć. (oczywiście wybiegłem raz do wpisania tekstu, by pokazac ci prostą walidacje vs rzutowanie i wpadka z zerem).
W tym temacie user zaznaczał checkboxy, on nic nie wpisywał. Zeby wiec wartosci checkboxów były złe, to user by musiał specjalnie grzebac w zródle strony by je podmienic i przeslac na serwer inne wartosci niz oczekiwalismy. I tutaj zwykle rzutowanie na liczbe jest wystarczające.
No chyba ze musimy sprawdzic czy wartosci są z danego zakresu, ale wówczas i ty i ja musismy dorobic dodatkową walidacje.

W przypadku gdy user wpisuje dane to i ja również robię walidacje jesli jest to niezbędne W tym przypadku zwyklych checkboxów walidacja nie była niezbędna - wystarczylo zwykle rzutowanie.

edit:
przeczytalem jeszcze raz twoj post i jednak odpowiem na jeszcze jedno

Slyszałem, ze postgre wywala sie gdy dla pola liczbowego uzyjemy ciapków. Nawet jesli mozna to zmienic w konfiguracji to miej na uwadze, ze nie kazdy ma mozliwosc zmiany konfiguracji bazy danych. WIec lepiej jak cos ma byc liczbą to niech sie to traktuje jako liczbe a nie jako tekst.

Nie jest tak zle ;-)



Ja tez powoli trace "werwe" ;-) Aczkolwiek, konstruktywna ta "klotnia" i chyba widac konsensus na horyzoncie :-)



W sumie - masz racje:-) Weszlismy w dosc glebokie niuanse, ktore maja znaczenie w konkretnych,
specyficznych sytuacjach - i problematyczne jest tego uogolnienie. A z kolei rozpatrywanie poszczegolnych przypadkow-
troche by zajelo i chyba rzeczywiscie szkoda na to czasu w tym kontekscie;-)



Domyslnie, dla poprawnych danych nie (np. dla 31 czy 22.14 ).Ale faktycznie,przypuszczam ze modyfikacja ustawien moze to zliberalizowac podobnie jak w innych systemach . Czasami mozna to sobie dopasowac samemu na poziomie sesji,czasami nie.

Jesli chodzi o dostep do konfiguracji serwera - masz racje, nie zawsze go mamy. Podalajac ta notke
w kontekscie calego watku - czyli przeniesienia z MySQL na inny system - mialem na uwadze to,ze gdy
przenosi sie aplikacje ze slabszego na mocniejszy rdbms jest zwykle ku temu istotny powod (wydajnosciowy lub
funkcjonalny) - i wtedy ten rdbms pracuje wylacznie dla naszej aplikacji - co pozwala zmienic dowolnie ustawienia.
(w kazdym razie - w moim wypadku zawsze tak bylo).

Ale , moze oczywiscie byc tez inaczej (np. gdy przenosimy aplikacje na wspolny,firmowy serwer oracla)... -i szkoda naszego czasu na rozpatrywanie tutaj kolejnych tysiecy opcji :-) :-)

W kazdym razie - dzieki za dyskusje :-)

Pozdrawiam serdecznie,
Kacper

Ostatnio jeden z uzytkowników "smiał powiedziec ze sie myle" ( ) nie zwracając uwagę na ciapki w zapytaniu dla liczby. Ja nie zwracalem na to uwagi w tamtym temacie bo akurat wtedy nie to było przyczyną problemów. Ale to był uzytkownik postgresa i dla niego dawanie ciapkow dla liczb konczylo sie errorem bazy. Nie bylo dla niego zrozumiałe ze mysql pozwala na takie kwiatki
http://forum.php.pl/index.php?showtopic=141771&hl=
Dlatego w tym temacie tak mocno akcentuję ze liczba to liczba a nie tekst, bo w przyszlosc z powodu złych nawyków mogą byc niepotrzebne problemy.

A potem zyli długo i szczęsliwie czego tobie i sobie życzę