13 odpovědí na toto téma

[Subi]

Pokračování na téma pádu při importu změn z a:Drake

 

Mě to dělal jednoznačně nakopnutý záznam v databázi. resp. vždy pouze konkrétní keš. Napadá mě jestli do databáze aDrake v nějaké slabé chvilce nezapíše něco jinak než GG očekává, třeba listing místo textu jako blob, ale nijak jsem to nezkoumal, jenom mě překvapilo, že evidentně jinak uložený listing oproti ostatním keším aDrake dokáže bez problémů zobrazit.

Považoval jsem to za nakopnutou databázi, ale jestliže už nás je víc, pak je to možná jinak. Tu databázi snad ještě mám, tak zkusím mrknout blíž.

Přiložený soubor (y)

•  chyba.JPG   17,02K   2 Počet stažení

Tento příspěvek byl upraven od Subi: 30 listopad 2013 - 8:25

[Subi]

Kdyby to někoho zajímalo, tak přikládám databázi pouze se třemi body z čehož je jeden vadný (GCK8T2).

Nicméně aDrake s ní pracuje úplně v pohodě, včetně toho "vadného".

 

hmmm, nejde mi připojit...

 

tak alespoň takto:

http://uloz.to/xMRC5o2b/ad-cachedb-db3

Tento příspěvek byl upraven od Subi: 22 listopad 2013 - 21:36

[Subi]

Není vadný, je pouze jako blob.

[Subi]

Zkusil jsem ještě i jiný bod, který má listing jako blob (výsledek aktualizace keše z webu v aDrake) a ten projde v GG úplně normálně včetně exportu.

Tak je problém ještě zřejmě jinde.

[Petman02]

Také mě to napadlo, zda není problém po aktualizaci keše a nebo stažení nové keše přes live

[LudekV]

Koukal jsem na to a kratce to probral s HaLuMou. Vypadá to na problém při čtení listingu, který byl upraven v a:Drake (rozuměj importován přes Gc Live nebo z GPX). Ten je totiž uložený zazipovaný, GG má z historických důvodů ten sloupec deklarovaný jako text ne jako blob, takže to může zlobit. Pracujeme na tom.

Padá to při otevření keše i při exportu, prostě kdykoli je potřeba ten listing načíst.

[HaLuMa]

Tak jsem si pohral s tou keskou v te ukazane databazi.

 

Myslim, ze typem sloupce to nebude, protoze tu teto kese napriklad long description prectu a dekompresuji naprosto v pohode.

 

Problem je v Short Description, ze ktereho prectu pouhe dva byty dat 0x78 0x9C, a to rozzipovani se na tom vzteka. V Adrake prectes z toho shorddesc pole neco jineho?

[LudekV]

V a:Drake se to v pohodě načte, ale výsledkem unzipu je prázdný string. To je v podstatě správně, protože tam žádný text v Short Description není. Ty divné dva bajty jsou výsledkem zazipování stringu s jedinou mezerou.

U sebe jsem to ošetřil, takže od příští verze už to vznikat nebude. Pokud se povede to nějak ošetřit i v GeoGetu, bylo by to fajn.

[HaLuMa]

To je divne, kdyz u sebe zkusim prohnat ZLIBem prazdny string, tak dostanu: 78 9c 03 00 00 00 00 01, a to se mi take spravne rozbali jako prazdny string.

 

Takze jen to 78 9c vypada useknute, cemuz odpovida i ta chybova hlaska.

 

Kazdopadne v Geogetu delam to, ze prazdny string tou kompresi vubec neprohanim. A naopak, prazdny string neprohanim dekompresi.

[LudekV]

Máš pravdu. Krom toho, že jsem to zipoval vcelku zbytečně měl jsem i příliš malý buffer, takže se to tam celé nevešlo a došlo k tomu oříznutí. Každopádně platí, že v příští verzi a:Drake to bude opravené.

[LudekV]

Abych nezapomněl, a:Drake 4.08 už má tenhle problém opravený. Pokud už máte takto poničenou databázi jsou tyto možnosti, jak to spravit:

1. Nahrát do telefonu novou databázi z GeoGetu - nejlepší, pokud nejsou v telefonu změny, o které nechci přijít.
2. Problémové kešky v a:Drake onbovit z GPX nebo Gc Live, pak by měla synchronizace ožít.

[Petman02]

 

Abych nezapomněl, a:Drake 4.08 už má tenhle problém opravený. Pokud už máte takto poničenou databázi jsou tyto možnosti, jak to spravit:

1. Nahrát do telefonu novou databázi z GeoGetu - nejlepší, pokud nejsou v telefonu změny, o které nechci přijít.
2. Problémové kešky v a:Drake onbovit z GPX nebo Gc Live, pak by měla synchronizace ožít.

 

add 2. Jak poznám problémové kešky?

[LudekV]

Špatně. V podstatě jen podle toho, že na nich GeoGet spadne při pokusu o otevření listingu nebo export. Pokud vidíš do databáze, tak to jsou ty, co mají v shortdesc nebo longdesc "divný" obsah, tj. dva chybné bajty jako na obrázku.

Přiložený soubor (y)

•  vadnaDB.JPG   28,58K   4 Počet stažení

[LudekV]

Zjistil jsem, že oprava nebyla kompletní. Problémy způsobovaly i texty logů a nově importované keše. Ve verzi 4.14 už bude opravené i toto