Onlangs heb ik geprobeert om te dumpen naar MSSQL.
Heb eerst het MySQL create script omgebouwd, daarna daarmee een database aangemaakt en deze via een ODBC koppeling toegankelijk gemaakt.
Echter telkens crashed het hele zaakje wanneer ik probeer er naar toe te dumpen.
Mogelijk heeft het iets van doen met sommige columnamen die bij MSSQL gereserveerde identifiers zijn, deze moeten dan [gequote] worden, maar het kan ook goed aan iets anders liggen.
Dus⌠dump ik maar naar Access en probeer ik later van daaruit wel naar MSSQL te exporteren.
Zeg, waar kan ik die Java sourcecode vinden? Is het èrg veel? âŚom de boel te poorten naar bijvoorbeeld Delphi of C#? Het valt me namelijk op dat de boel zo ongeloofelijk traag is, waar komt dat door? Is dat omdat het in een virtual machine draait, of is de code zo inefficient? Het algorithme om de boel te kunnen ontcijferen? :?:
Onlangs heb ik geprobeerd om te dumpen naar MSSQL.
Super â)
Echter telkens crashed het hele zaakje wanneer ik probeer er naar toe te dumpen.
Mogelijk heeft het iets van doen met sommige columnamen die bij MSSQL gereserveerde identifiers zijn, deze moeten dan [gequote] worden, maar het kan ook goed aan iets anders liggen.
Even met RGJ contact (privat mail forum) opnemen om dit op te lossen.
Zeg, waar kan ik die Java sourcecode vinden? Is het èrg veel? âŚom de boel te poorten naar bijvoorbeeld Delphi of C#? Het valt me namelijk op dat de boel zo ongeloofelijk traag is, waar komt dat door? Is dat omdat het in een virtual machine draait, of is de code zo inefficient? Het algorithme om de boel te kunnen ontcijferen?
De opbouw zit er een beetje anders uit zoals jij het aangeeft. Het dumpen van de data wordt gedaan door dllâs die standaard bij de cdfoon worden bijgeleverd. De dllâs worden in java aangeroepen. Eigenlijk moet je foondump zien als een alternatieve GUI programma voor de cdfoon. Het dumpen duurt wel lang, echter we hoeven geen tijd te steken in tekens veranderen files van de cdfoon. Het dumpen in achtergrond op je pc heb ik niet zoân moeite mee dat het een paar dagen duurt. Veel belangrijker is dat het bij iedereen goed werkt.
Eindgebruikers kunnen super professionals zijn maar ook mensen die bij wijze van spreken ânet hun pc kunnen opstartenâ,
Kan je de foutmeldingen die je krijgt hier posten?
Je kan Foondump niet eenvoudig porten omdat het met JNI DLLâs van de Cdfoongids aanroept. En ook al zou het lukken dan wordt het er geen seconde sneller van. De traagheid zit in het algoritme, en dat âhergebruikenâ we dus van de orginele code.
Java source is bij mij aan te vragen maar alleen met als doel het verbeteren van de code en het toevoegen van nieuwe features.
Maar hebben jullie wel een idee hoe die tabellen in elkaar zitten?
Ik bedoel de compressie dan wel versleuteling van de databestanden op de CD-foon?
Als ik een blik werp zie ik een xBaseJ-ding, wordt daar bijvoorbeeld wel iets mee gedaan of is dat alleen voor het personal addressbook of zo?
Met enige welwillendheid zou je namelijk in de naamgeving van de bestanden op de CD-foon een dbf-structuur kunnen zien.
Experiment: Pink-postcodes geexporteerd naar een DBF-tabel.
In âZIPCODE.Bâ en in een ongecomprimeerde DBF-tabel zitten wel allebei 4x16 bijna lege headerregels.
Die DBF-tabel gewoon comprimeren met WinZip is te drastisch in vergelijking met âZIPCODE.Bâ, het bestand wordt te klein en de âtextuurâ van de gecomprimeerde data ziet er heel anders uit. Het idee dat het in een of andere vorm gezipt is was sowieso onwaarschijnlijk want waar zijn anders de hulptabellen met de âIâ in de extensie voor nodig. In tegenstelling tot de inhoud van de zip vertoont een histogram van letterfrekwenties in âZIPCODE.Bâ wel enige periodiciteit, dezelfde als bijvoorbeeld die van de witte âZipcode.bâ.
Kortom, is een van jullie al een keertje intiem geweest met het binnenste van deze tabellen?
Ik bedoel de compressie dan wel versleuteling van de databestanden op de CD-foon?
Maar hebben jullie wel een idee hoe die tabellen in elkaar zitten?
Dat is een heel tijd geleden dat ik naar âde tabellenâ heb gekeken.
Omdat huidige cdfoon met een tender is gebouwd ga ik er vanuit dat het over een jaar of zo mogelijk weer in andere handen zal gaan.
Het levert m.i. niet veel meerwaarde op om het te gaan uitzoeken. Ik denk dat we beter onze kostbare tijd in DM/KvK/Routeplanner kunnen steken. Als we die cdâs dumpen hebben we meer info die we nu nog niet hebben.
Het idee dat het in een of andere vorm gezipt is was sowieso onwaarschijnlijk want waar zijn anders de hulptabellen met de âIâ in de extensie voor nodig.
Een groot bestand wordt niet in zijn totaal gezipt maar in blokken. Je heb een bepaalde postcode nodig. Dan weet je dmv. een I (index) bestaand welke blok je moet unzippen (7523 geeft blok x). Zou best logisch zijn dat ze een compressie methode gebruiken die vrij is van auteursrechten.
Kortom, is een van jullie al een keertje intiem geweest met het binnenste van deze tabellen?
[quote=âWeermanâ]Maar hebben jullie wel een idee hoe die tabellen in elkaar zitten? Ik bedoel de compressie dan wel versleuteling van de databestanden op de CD-foon?
Kortom, is een van jullie al een keertje intiem geweest met het binnenste van deze tabellen?[/quote]
Ja, ik.
De vorige versie van de tools, Babyfoon/Portofoon en Megafoon 1.0 maakten gebruik van code die rechtstreeks de tabellen benaderde. Die code heeft tegen de honderd uur werk gekost. En toen veranderden ze de opbouw van de tabellen. En toen weer de indexbestanden. En toen weer eens het compressiealgoritme. En toen hebben we besloten om het anders te doen, omdat het duidelijk was dat Telemedia met heel weinig werk ons elke 3 maanden opnieuw heel veel werk kon bezorgen.
De huidige versie van Foondump kost meer tijd runtime, maar een factor minder werk development time.
dump ik maar naar Access en probeer ik later van daaruit wel naar MSSQL te exporteren.