Biztos jó, amúgy találtam én is módszereket de én még életemben nem léptem be pld parancssorral. Ha valami nincs ftp-n vagy cPanelen akkor nekem az már a túloldal, meg sem próbálom.
Talán azt próbálod mondani, hogy az oldaladban lévő PHP-nek valami baja van, ezért HTTP 500 jön a szervertől. Végső esetben a szerveren az error_log-ot lehetne megnézni.
Nem is a kódrészlet az érdekes, mert az csak egy függvényhívás. Az egésznek annyi a lényege, hogy időnként a szerver nem válaszol időben. És addig nem tudok új adatot kérni. Nyilván ilyenkor maga a program is áll, tehát valami "oldalszál" kéne, ami csupán ezt az egy függvényhívást jelentené és csak annyi ideig létezne, amíg a válasz meg nem jön. A másik gondom az, hogy van egy globális változóm, aminek viszont folyamatosan léteznie kéne, ezért a "főprogramot" nem szakíthatom meg.
Úgy érted, hogy a curlopt_timeout megszakítja a kérés-függvényt, ha nem érkezik válasz meghatározott időn belül?
Adott egy szolgáltató, akinek van egy api felülete, azon keresztül lehet tőlük adatokat kapni.
Korábban böngésző-js-php útvonalon kértem. A js oldotta meg az időzítést, a php meg a kapcsolatot a szolgáltatóval.
Ha az adat nem jött meg, a js időzítése akkor is utasította a php-t az új adat lekérésére.
Most én a böngészőt és a js-t kiiktattam, praktikus okokból és nem is szándékozok használni, hanem cli-t használok, de a következő problémám akadt. Eddig minden jól ment úgy, hogy php-lekérés, válasz jött, feldolgoz, megjelenít, új kérés.
Igenám, de a szolgáltató úgy döntött, hogy időnként késlelteti a választ, ami az én céljaimnak nem felel meg. Ilyenkor a programom újraindításával oldottam meg, de nem tudok mindig a gépnél lenni, az adatok meg kellenek.
Úgy néz ki a kódrészlet, hogy
$response = apiRequest();
És itt véletlenszerűen megáll határozatlan időre a program futása, esetenként megkapta a választ 5-10 másodperc múlva, akkor tovább fut, de nekem az már késő. Azt kéne megoldani, hogy ha nem jön 2 másodpercen belül válasz, akkor kérjen újat, az előző lekérést pedig felejtse el. Megoldható ez vajon úgy hogy a php program futását nem szakítjuk meg?
Az ötleted sajnos nem jó. Lehet, hogy én nem voltam egyértelmű, de megpróbálom másként: van egy webshop, aminek van kb. hatféle kötelezően megjelenítendő dokumentuma, pl. hivatalos adatok, szállítási költségek, copyright infó, stb. Ezeknek a doksiknak van n+1 verziójuk, és ezek mind egy (documents) táblában vannak.
A formulád sajnos csak a legutoljára mentett dokumentumot adja ki, bármelyik is legyen az. Nekem mindegyikből az utolsó verzió kellene, egyszerre. Ezt hozza is a képletem, csak bíztam benne, hogy ismertek egy egyszerűbb módot, mint a FROM ( SELECT ... ). Úgy tűnik, hogy azért kell a FROM ( SELECT ... ), mert ha mindent a documents táblából kérek le, akkor a SELECT DISTINCT (próbálok jól fogalmazni) az egyes sorok összes lekért mezőjének összegéből válogatja az egymástól különböző értékeket, azaz hiába írom, hogy ... DISTINCT ( docTitle ), docRecDate, mégis ugyanannak a dokumentumnak minden verzióját megkapom, vhogy így:
about_us 2012-12-24 18:00:00
about_us 2013-01-31 23:59:59
t_and_c 2012-10-31 12:34:56
t_and_c ...
Ha viszont a documents táblából doc alias alatt másolatot készítek és arra hivatkozok, akkor jó eredményt kapok. Csak nem voltam biztos abban, hogy ez az optimális eljárás.
Van egy MySQL tábla, amiben többféle doksi van eltárolva, mindegyik annyiszor, ahányszor módosult (a leghosszabb is csak 4000 karakter körül van). A docTitle az azonos témájú dokumentumoknál megegyezik, a különbséget az egyes verziók dátuma adja:
docTitle, docBody, docRecDate
Ki kéne nyerni minden doksiból a legújabb verziót. Több zsákutca után erre jutottam:
Nem volna rossz, ha ténylegesen elkezdenél debuggolni. Értem, hogy nehéz, meg hexakódokat táblázatokból kikeresgélni unalmas, de gondolj arra, milyen jó lesz, ha már készen leszel.
Sziasztok!
Nem voltam gépnél a napokban...
Pontosan mire gondolsz? Az adatbázishoz nem tudok hozzányúlni, az ékezetes oszlopnevek maradnak sajnos...
Valahogy nem lehet konvertálni a conn stringet utf-16-ra, mert alapból arra panaszkodik, php scriptet meg hagynám ansii-ban iis-7 alapból kéri, aztán talán
mikor vissza kapom a query eredménYét, akkor ismét convertálnék utf-8 vag 16- ba...
Tanácstalan vagyok...
Én mindenképp elkezdeném a migrációt. Nemtudom milyen adatbázis, csak lehet valami aliast vagy view-t csinálni, aminek már rendes neve van. Minden új kód az aliast hivatkozza, minden problémás esetet úgy oldok meg hogy az adott kódot átírom ékezetmentesre. Így persze örökre marad kód ami az ékezetest hivatkozza, de ha bármivel gond van, meg tudom oldani hamar.
perszehogy érdekel! ez az internet lényege. lesz még aki belefut ebbe, és a google meg fogja neki találni ezt a fórumot. örülni fog ha a megoldás is itt lesz, nemcsak a probléma.
Ilyen jelecske akkor szokott megjelenni, amikor utf8-at ígérünk, de helyette egybájtos kódot küldünk. Meg kellene nézni egy hex-viewerrel a scriptedet, hogy igazból utf8-e van benne. No meg ezt is meg kellene nézni: http://web.axelero.hu/lzsiga/ekezet.html
Sajnos ezen már nem tudok változtatni. Ezt elszúrták. Én is azt olvastam a neten, hogy ékezetes betűket ne használjak column névként, de nem én csináltam az adatbázist, és az egyik intraneten hiba nélkül működik.
ha neked is kockában kérdőjelet mutat a hibaüzenetben, akkor tuti arról van szó hogy van benne olyan karakter ami megfekszi a gyomrát. lehet hogy az é elmegy, de az ő vagy ű-be belehal.
muszáj leszoknod az ékezetes objektumnevekről. még ha a gyártó azt is mondja hogy támogatja, nagyokat fogsz szívni vele. a profik sosem használnak ékezetes neveket, ezért rengeteg bug ami ezekkel kapcsolatos nincs felfedezve sem, vagy ha igen, senkit nem érdekel.
Ez lenne a legkézenfekvőbb megoldás, de a mezők átnevezése nélkül is működik az egyik helyen a lekérdezés. A probléma pont abból adódik, hogy három másik alkalmazás is használja ezeket az adatbázisokat, melyeket nem tudok átírni. A futtató környezet mindenhol azonos / legalábbis azt kell hinnem, mindenhol én raktam fel az iis 7.5-öt és php-t /, az adatbázisok egyformák, hiszen mindhárom helyszínen ugyanazok az alkalmazások használják ezeket.
Amikor átmásoltam a .php-ket a másik gépre, először a connection paraméterekre panaszkodott, hogy nem tudja átkódolni őket. Elmentve ezeket utf-8-as kódolással, már csak szintaktikai hibára dobott hibát, mely szerint '?' itt található a hiba. Megpróbáltam 'szállodák' ezt is, akkor vmilyen másik helyen írta ugyanazt a hibát. []-ba zárva sem enged tovább, bármit teszek.
Az alkalmazás a másik helyen , ahol működik , ott változókat is küld insert-hez, update-hoz is, és ott mégis megy.
Az összes ékezetes tábla és mezőnevet át kellene nevezni: SZÁLLODÁK->SZALLODAK/HOTELS; SZÁLLODA_NEVE->NEV/NAME.
PS: ja és a TERMEK nevű táblában egy TEREM nevű mező nem fejez ki semmit... legyen az 'ID' vagy 'SZAM' vagy 'NEV' de utaljon a mezőtartalom mibenlétére
Segítségeteket kérném, új vagyok az oldalon, közel az ötvenhez és hobbiból készítek alkalmazásokat.
A következő a problémám:
Adott a környezet 3 gépen /win7 prof, php 5.6.18, iis with fastcgi, mssql server/, mindhárom más-más intraneten van.
Készítettem egy alkalmazást, amelyik php-n keresztül kérdezi le az mssql servert. Egyszerű select,insert,update stb. van szó, változókkal ill anélkül.
Az egyik helyen tökéletesen működnek a dolgok, a másik kettő helyen valamiért nem.
Itt a két egyszerű select script, az első működik, a második nem. Az mssql szerverek ugyan olyanok, schema és adatok is bennük ugyanaz. Win7 pro is ugyanaz mindhárom helyen, iis 7.5 ugyanaz.
Kapcsolat mindenhol létrejön, utf-8 a scriptek kódolása, mert asci-ben mentve a conn stringre panaszkodik, hogy nem tudja a karaktereket átkódolni.
Valakinek tanácsa?
Sok mindent próbáltam már, szívesen csevegnék róla...