1059 odpovědí na toto téma

[gord]

Jednu chybku jsem tam nasel - chybne zpracovani znaku '+' v nicku pri RegEx hledani vlastnich kesi. Ale to by rozhodne nemelo zpusobovat nutnost tohoto prostouchnuti. Take nevidim duvod, pro po nem by se to melo zmenit, kdyz se vrati puvodni nastaveni. Navic seznam ignorovanych kesi nema nic spolecneho se seznamem zpracovavanych vlastnich kesi, ktery se plni podle nicku uzivatele. Spis bych rekl, ze se zmenilo jeste neco, na co DA+RA zapomnel zminit (nebo si tu zmenu treba ani neuvedomil).

[petulinka1]

Nebo to treba bylo neulozeny v ini a temahle hratkama se to ulozilo (nebyl by to prvni pripad, kdy se hodnota odmitala zapsat. Otazkou ovsem zustava, odkud to pak formular neustale nacita

[gord]

Ne, to nemuze byt ten pripad. Pokud je seznam kesi ke zpracovani prazdny, automaticky se nastavuje zpracovani vsech. Takze mi z toho opravdu vychazi jen to, ze nebyly nacteny kese patrici prislusnemu autorovi. To se zjistuje dvema mechanismy:

 

- pomoci regularniho vyrazu, tam je to nezavisle na velikosti pismen, ale bylo tam spatne zpracovani znaku +

- pomoci presneho nicku (nebo vyjmenovanych nicku), to je zavisle na velikosti pismen

 

Jelikoz DA+RA ma v nicku to nestastne +, odtud se zadne kese najit nemohly. A protoze se nenasly vubec, musel byt i druhy krok neuspesny. Tedy musel byt spatne zapsany nick v seznamu autoru. Jestli velikosti pismen nebo treba nejakou mezerou navic nebo co ja vim ... Jinou moznost opravdu nevidim.

 

Ale to jsou technicke veci, tady jsme trochu OT.

[DAplusRA]

V nastavení mám DA+RA, zajímavé je že ve složce profiles mám názvy složek - DaRa,default a Default_notabs. Ale to je jedno, hlavně že to funguje

[gord]

Pro jmen adresaru je treba nektere znaky vypustit a u jinych znaku to sice potreba neni, ale je to vhodne. Takze ta jmena adresaru v Profiles jsou spravne.

[Jerry33]

Ahoj,

 

zase po nějaké době používání a zkoumání přicházím s pár návrhy ke Statoru:

 

V modulu Numbers, část Locations bych smazal souřadnice uváděné za každou keší. Jednak je to tam zbytečné a v případě, kdy je název keše dlouhý, tak ty souřadnice skočí na další řádek a nevypadá to pěkně. To samé se stalo mě u nejvýchodnější keše. Nyní už jsem si ty souřadnice odstranil, takže to vypadá lépe.

 

Dále v části Age (respektive asi to platí pro celý modul) se nejspíš špatně počítá šířka sloupce (viz moje Nejmladší keš). Takže teď když tam mám keš z 10.12. tak rok 2014 je už na dalším řádku. Tomuhle jsem na kloub nepřišel, ale chtělo by to vyřešit tak, aby datum bylo na jednom řádku. Od toho se pak předpokládám odvíjí to, že i kód keše skočil na další řádek.

 

A na závěr dotaz - zdá se mi, že od začátku používání Statoru se ani jednou nezměnila čísla u disablovaných a archivovaných keší a to je mi více než podezřelé. Musím to asi nějak zaktualizovat v Geogetu, že?

[gord]

Sirky sloupcu: to je vec toho, jak si je nastavi browser. V podstate neni mozne predepsat sirky vsech sloupcu v tabulce, breoser toto nastaveni pak bude ignorovat. Ve Statoru se nastavuje sirka jen u vybranych typu sloupcu, ostatni si dopocitava prohlizec jak ho napadne, vnucovat si nic nenecha. A aby to nebylo malo, kazdy z nich se chova trochu jinak.

 

Pocty disablovanych a archivovanych jsou cteny z databaze. Pokud se ti v databazi pocty nezmenily, museji byt i ve Statoru stejne. Jakym zpusobem a jak casto aktualizujes stav (disable/archived)?

[dandu1]

Mám dotaz. U statistiky v tabulce "První nález ve státě" je u datumu uváděna i hodina nálezu. Rád bych ji smazal, protože hodinu u většiny keší nemám zapsanou. Jak to lze udělat?

A ještě jeden dotaz. V tabulce "Nejlepší hledaci mých keší" je uváděn na prvním místě hledač Richard2007 se třemi nálezy, ale já mám založeny jen 2 kešky. Kde je chybička? Díky za radu

   

[gord]

Cas nalezu jse mozne vyhodit. Nevim ted, zda mas tabulku tvorenou pomoci modulu SQLTable nebo CustomizedTable. Je treba zmenit parametry modulu. Pokud je to CustomizedTable, tak misto sloupce datum+cas pouzit jen sloupec datum. U SqlTable je to podobne, ale musi se upravit primo ten SQL.

 

A co se tyka tech nalezu, odhaduji, ze na nektere kesi ma 2 nalezove logy.

Tento příspěvek byl upraven od gord: 14 prosinec 2014 - 15:07

[Jerry33]

Stav nalezených kešek aktualizuji přes Databáze-Import-Aktualizovat Vaše nálezy 

 

Nicméně si nejsem jistý jestli tím dosáhnu chtěného efektu?

[gord]

Nedosahnes. To aktualizuje nalezy, ne kesky. Upresnim: tim stahujes aktualni logy (ne jen nalezove, jak by se mohlo zdat z nazvu funkce). Informace o keskich si tato funkce vubec nevsima a vsimat nema.

 

Oznac nalezene kese a v kontextovem menu vyber funkci Aktualizovat stav kese.

[Jerry33]

Ach, opět to bylo mojí neznalostí. Děkuju gorde! :-)

[dandu1]

Mám dotaz pomocí SQL. Ale jsem na to mimoň. Co mám smazat aby se čas nezobrazoval?

Viz přiložený soubor

 

Přiložený soubor (y)

•  SQL dotaz.doc   22K   175 Počet stažení

[kiReGPS]

Vezmeme to zgruntu. Pro přehlednost uvedu tvůj původní SQL dotaz (pro mne docela vtipně) schovaný ve wordovském souboru:

select id, cachetype "Type icon", Name, country "Country flag", dtfound||dttime "Found datetime"
from (
    select gc.id, gc.name, gc.cachetype, gc.country,
    substr(gc.dtfound,7,2) || '.' || substr(gc.dtfound,5,2) || '.' || substr(gc.dtfound,1,4) as "Found_date",
    gc.dtfound, substr("0000"||gc.dtfoundtime,-4,4) dttime
    from geocache gc
    where gc.dtfound>0
    order by gc.dtfound || dttime desc
)
group by country
order by dtfound || dttime asc

Odpověď by mohla znít velmi jednoduše - na prvním řádku dej místo "Found datetime" jen "Found date". A bylo by hotovo. Stator totiž při vypisování obsah pole formátuje podle jména aliasu (to je to "Found date"). Více najdeš v dokumentaci.
 
To, že formátuje Stator, zároveň znamená, že nemusíš pracně formátovat ty. Nemusíš tedy rozhodně skládat datum z částí s tečkovým oddělovačem. Jiná věc je, že dotaz je špatně. Pole dtfoundtime obsahuje čas jako číselnou hodnotu. Spojením stringů tedy nevznikne údaj, jehož abecedním řazením získáš správnou posloupnost nálezů. S hodnotami data a času nálezu musíš pracovat jako s číselnými. Pak ti taky chyběly aliasy ve vloženém selektu. Sumasumárum jsem ti dotaz upravil na:

select ID, CacheType "Type icon", Name, Country "Country flag", Found "Found datetime"
  from (
    select gc.id ID, gc.name Name, gc.cachetype CacheType, gc.country Country, gc.dtfound*10000+gc.dtfoundtime Found
    from geocache gc
    where gc.dtfound>0
    order by Found desc
  )
group by Country
order by Found

P.S.

Někteří nejmenovaní šťouralové by jistě ještě poznamenali, že řazení nálezů by správně mělo být udělané podle pořadí definovaného v nastavení Statoru. Informace o pořadí je pro selekty dostupné v dočasné tabulce temp.Stator (opět viz dokumentace).

[gord]

Ja bych to tedy upravoval jinak, ja bych jen vyhodil tu casovou polozku:

select id, cachetype "Type icon", Name, country "Country flag", dtfound
-- ||dttime "Found datetime"  --- tento radek je pro datum a cas
"Found date"           --- tento radek je pro detum bez casu
from (
    select gc.id, gc.name, gc.cachetype, gc.country,
    gc.dtfound, substr("0000"||gc.dtfoundtime,-4,4) dttime
    from geocache gc
    where gc.dtfound>0
    order by gc.dtfound || dttime desc
)
group by country
order by dtfound || dttime asc

Vyhodu to ma v tom, ze je spravne razeni i v pripade, ze je cas uveden. Je potlacen jen jeho vypis.

Tento příspěvek byl upraven od gord: 16 prosinec 2014 - 8:12

[kiReGPS]

Jenže právě to řazení je tam špatně:

order by gc.dtfound || dttime

...dává špatný výsledek. Nálezy mezi třetí a devátou hodinou ranní budou zařazeny až za všechny ostatní...

[gord]

Urcite? Mas to vyzkousene? dttime je vzdy na 4 znaky, zleva doplnene nuly.

[kiReGPS]

Zkoušel, proto to tady píšu...  Výraz "dtfound||dtfoundtime" dává pro nález 15.prosince 2014 v jednu hodinu ráno hodnotu "20141215100"...

[gord]

No, tak mimo vlakno jsme se dohodli, ze mam ten SQL spravne. Pokud pouzijes presne to moje, bude to spravne. A v novem vydani Statoru bude ten modul jiz obsahovat tento SQL.

[dandu1]

Díky moc