705 odpovědí na toto téma

[gord]

Je trochu skoda, ze jsi porovnal jen vysledky, ale uz jsi neporovnal oba SQL. Tam by bylo jasne videt, podle ceho se radi a jak.

 

Problem muze byt jeste jeden. Pokud se nepletu, stare logy vubec nemely gsid, ta polozka proste nebyla. Koukal jsi se do databaze, jakou maji hodnotu? Pokud je pri razeni hodnota stejna, pak zalezi na ostatnich parametrech razeni a v pripade, ze i ty jsou stejne, tak muze byt vysledek i nahodny.

[Zagloba]

A nemělo by být to řazení podle gsid v tom vnitřním selectu? V tom vnějším to podle mě nemá význam.

[Re0]

Rad bych mrknul, ale vůbec netuším, kam bych se měl na ty informace podívat.... případně, jestli by se pak třeba to gsid dalo ručně doplnit, aby to fungovalo, jak má...

[kiReGPS]

Napsal to Gord, ale nikdo tomu nevěnoval pozornost. Prosím Re0 o následující:

• dej si do svojí statistiky jak svůj původní výstup pomocí CustomizedTable, tak nový pomocí SQLTable (nejlépe hned za sebou)
• vygeneruj statistiku (stačí náhled)
• pošli nám soubor Stator.log (najdeš ho ve tvém profilu ve Statoru)

Díky...

[Re0]

Napsal to Gord, ale nikdo tomu nevěnoval pozornost. Prosím Re0 o následující:

• dej si do svojí statistiky jak svůj původní výstup pomocí CustomizedTable, tak nový pomocí SQLTable (nejlépe hned za sebou)
• vygeneruj statistiku (stačí náhled)
• pošli nám soubor Stator.log (najdeš ho ve tvém profilu ve Statoru)

Díky...

 

Tak přikládám...  snad to pomůže.

Přiložený soubor (y)

•  Stator.txt   65,36K   232 Počet stažení

[gord]

Ja z toho logu vyberu jen ty SQL ...

13:06:51.082  Modul CustomizedTable (První keš podle země)
13:06:51.171  SQL= SELECT (SELECT value FROM geotagvalue WHERE key=gT100.ptrvalue) valT100, 
   gc.dtfound, st.rowid, gc.country, gc.country, gc.cachetype, gc.cachestatus, 
   CASE (gc.cachestatus) when "0" then "+"||gc.name when "1" then "-"||gc.name when "2" then "#"||gc.name else "?"||gc.name END,
   st.distance
 FROM temp.Stator st, geocache gc
JOIN geotag gT100 ON (gc.id=gT100.id and gT100.ptrkat IN (SELECT key FROM geotagcategory   WHERE value=:TagCat_T100 COLLATE NOCASE))
WHERE gc.id=st.id
 GROUP BY gc.dtfound
 ORDER BY gc.dtfound asc
13:06:51.172  Stop SQL
...
13:06:51.655  Modul SqlTable (První nález ve státě)
13:06:51.741  SQL=select rowid "Order by finds", country "Country flag, text", dtfound "Found date=Right", id, cachetype "Type icon", Name
from (
    select st.rowid rowid, gl.id id, gl.gs_logid gsid, gc.name name, gc.cachetype cachetype, gc.country country,
    gc.dtfound dtfound, substr("0000"||gc.dtfoundtime,-4,4) dttime
    from temp.Stator st, geocache gc, geolog gl
    where gc.id=gl.id
      AND gc.id=st.id
      AND gl.finder="Re0"
      AND gl.type IN("Found it", "Attended", "Webcam Photo Taken")
      AND gc.dtfound>0
    order by gc.dtfound || dttime desc
)

group by country

order by dtfound, gsid

To jsou dost neporovnatelne prikazy. Netusime, co presne je obsahem tagu, podle ktereho se v prvnim pripade vybira. A uz vubec netusime, co mas opravdu v databazi, zda jsou ID logu vzestupne nebo jsi nekdy (treba omylem) zalogoval kesky v trochu jinem poradi nez jsi je nasel.

 

Zabyval bych se jen tim druhym SQL. Je mnohem rozumnejsi, protoze pracuje opravdu jen s datem/casem nalezu a pripadne s ID logu. Vysledny vystup je razen napred podle data nalezu a pak podle ID logu. Pokud tvrdis, ze jsi kesky nasel v jinem poradi nez dava tento vystup, pak tvrdim, ze mas budto spatne datum nalezu nebo nemas vzestupne (v jednom dni) ID logu, a tedy jsi kese z toho jednoho dne zalogoval v jinem poradi nez jsi je nasel.

[Re0]

 

Zabyval bych se jen tim druhym SQL. Je mnohem rozumnejsi, protoze pracuje opravdu jen s datem/casem nalezu a pripadne s ID logu. Vysledny vystup je razen napred podle data nalezu a pak podle ID logu. Pokud tvrdis, ze jsi kesky nasel v jinem poradi nez dava tento vystup, pak tvrdim, ze mas budto spatne datum nalezu nebo nemas vzestupne (v jednom dni) ID logu, a tedy jsi kese z toho jednoho dne zalogoval v jinem poradi nez jsi je nasel.

 

Díky moc za analýzu....  ale jsem si opravdu jist na 100%, že loguji keše přesně podle pořadí nálezu. Kdyby mi to dělalo u jedné, OK, beru, že jsem se někde spletl, Ale je to ve více případech.

Dá se někde u keše zjistit ID logu ???  abych to mohl nějak potvrdit ???

[gord]

V tom pripade opravdu jedine vypsat ID logu a daum z databaze, abychom si dokazali, co je spatne.

[gord]

Spust databazovou konzoli a zadej tam 

SELECT id,dt,gs_logid, finder FROM geolog WHERE dt='20080817' AND finder='gordici' ORDER BY gs_logid;

za datum dej to se spornym nalezem a pochopitelne svuj nick. Vysledek nam se ukaz.

Tento příspěvek byl upraven od gord: 26 únor 2018 - 17:36

[Re0]

Spust databazovou konzoli a zadej tam 

SELECT id,dt,gs_logid, finder FROM geolog WHERE dt='20080817' AND finder='gordici' ORDER BY gs_logid

za datum dej to se spornym nalezem a pochopitelne svuj nick. Vysledek nam se ukaz.

 

Rád bych ukázal, ale nevím co.  Dělám něco špatně ?

Přiložené miniatury

• 

[gord]

Na konci chybi strednik. (Moje chyba, zapominam, ze konzola ho vyzaduje i kdyz je jen jeden prikaz.)

[Re0]

Tak pokud výsledkům dobře rozumím, moje logování je bez závad. Vždy ta, která je mou první ve státě, má nejmenší IDlogu.

Přiložené miniatury

• 

[gord]

Pak muze byt jeste problem v dtfound u prislusnych kesi nebo v tom SQL pouzitem vyse (priznavam, nijak hluboko jsem jej nezkoumal.

SELECT gl.id, gl.dt, gc.dtfound, gl.gs_logid, gl.finder 
  FROM geolog gl, geocache gc
  WHERE gl.dt='20080817' AND gl.finder='gordici' AND gl.id=gc.id
ORDER BY gs_logid;

pribude tam navic sloupec s datem nalezu (ten prvni je datum logu!)

 

Jeste drobnost. Ja netusim, kterou kesku ocekavas, ze by mela byt v seznamu na zacatku. Takze je na tobe, abys to overil.

Tento příspěvek byl upraven od gord: 26 únor 2018 - 18:56

[Re0]

Tento příkaz mi v konzoli taky nic nedělá....

Ale asi se na to vykašlu, nechci otravovat s takovou blbostí.... protože ostatní s tím asi nemají problém....

[gord]

A opravil jsi tam datum a finder? Mne to vraci bez problemu to, co ma.

 

Jestli se ted na to vykasles, tak to me vazne nastves. Kdyz se s tim nekdo zacne zabyvat, aby nasel problem, tak toho chces nechat? Nejde o to, ze s tim maji nebo nemaji ostatni problem, ted uz mi jde o princip - najit chybu, ktera tam proste nekde byt musi.

[Re0]

Už mi to taky dělá....  jsem tam omylem odmazal jednu uvozovku :-(.

Nicméně, pořád mi to ukazuje, že ty logy mám OK...

Nicméně, ořešil jsem si to tím, že jsem si u těch prvních keší ve státě dopsal čas 00:01 a u těch dalších 00:02 (ikdyž normálně časy neloguji, a už to vyplivne keše, které má....

 

Pokud bys chtěl, klidně Tě pustím mrknout se přes TeamViewer, aby se třeba přišlo na to, kde je problém.....

 

Přikládám výpis konzole a keše, které jsou optavdu moje první

Přiložené miniatury

• 
• 

[mpik]

Tohle jsem psal už před časem, že pokud jsem chtěl správné pořadí, doplnil jsem odhadem časy. Teď loguju většinou z draftů z Adrake (jen loguju, hledám Oregonem) a tam mám čas v šabloně logu, takže se mi načítá automaticky. Někdy jsem to neřešil a mám tedy nálezy z jednoho dne zpřeházené.

Jestli se dořeší správné řazení i bez časů, bude to dobře, ale nepřipadá mi to tak důležité.

[gord]

mpiku, to spojujes nekolik problemu. Dulezite je, kde koukas na poradi nalezu (jak je to poradi sestaveno).

 

Stator ma pracovni tabulku, ktera obsahuje nalezy razene podle takovych kriterii, jaka si uzivatel zvolil. Pri te volbe by mely byt zohledneny zvyklosti uzivatele: 

 

• pokud vzdy zadava cas nalezu, je vhodne tento cas pouzit jako radici kriterium a pak nemuze byt poradi spatne
• pokud neni cas zadavan vubec, je zbytecne jej jako kriterium pouzit a je vhodne pouzit ID logu. To ovsem vyzaduje sprave poradi logovani
• pokud je nekdy cas zadan a jindy ne, pak se domnivam, ze spravne poradi bude pri stejnem nastaveni jako v prvnim pripade

To se ale bavim o pracovni tabulce! Pokud nejaky modul pouziva vlastni SQL, kde jsou kriteria razeni zakleta primo do toho SQL a nebere se v uvahu poradi v pracovni tabulce, je to jeho vec a je treba jej upravit. Nebo pouzit takove SQL, ktere pouzije pracovni tabulku. Pro vyse uvedeny pripad Prvni kese ve state vypada to SQL takto:

select num, country "Country flag, text", dtfound "Found date=Right", id, cachetype "Type icon", Name FROM
(SELECT st.rowid as num, country, dtfound, st.id, cachetype, name
  -- v pracovni tabulce jsou jen nalezy a jsou spravne serazene
  FROM temp.Stator st, geocache gc
  WHERE st.id=gc.id
  ORDER BY st.rowid desc
)
GROUP BY Country
ORDER BY dtfound

Pracovni tabulka obsahuje jen nalezy a ty jsou serazene spravne (tedy podle kriteria, ktere si urcil uzivatel s ohledem na sve praktiky). To byl hlavni duvod pro jeji vytvoreni - zrychlit a zjednodusit jine dotazy pracujici s nalezy. Proto by mel byt tento SQL take podstatne rychlejsi nez SQL, ktere pracovni tabulku nepouzivaji (viz predchozi prispevky).

[gord]

Jeste me napada jedna dulezita vec: Cas 00:00 znamena nezadany cas, ne pocatek dne! Takze pokud je nekdy cas zadany a nekdy ne (v jednom dni), pravdepodobne razeni v tom dni nebude spravne.

 

Jen tezko je mozne napravit chybne nebo alespon nesystematicke zadavani dat pozdeji nejakym zpracovanim. Takze budto vzdy piste cas nebo nikdy a pak logujte presne v poradi, v jakem jse kese nalsi.

[Pontiac_CZ]

Ha, takže přesně o půlnoci nelovit...