🚀 go-pugleaf

W dniu 10-02-12 23:59, 3P pisze:
> Problemy
> 1. Jak plik jest postaci pierwszyczlon.drugi.txt to OleDb nie potrafi
> zrobić SELECTA do takiego pliku. Jak zmienię mu nazwę na jedenczlon.txt
> jest ok - to mniejszy problem.
>
> 2. OleDb zwraca mi wszystko jako jedna kolumnę. Jak zmienię separator na
> ';' to działa. W sieci znalazłe, że do ConnectionStringa mogę dodać
> FMT=Delimited(x), gdzie x jest separatorem. Guzik prawda, nie działa to.
> Na stronach MS pisza o utworzenie pliku schema.ini
> http://msdn.microsoft.com/en-us/library/ms709353(VS.85).aspx i tam
> ustawieniu separatora (Format = Delimited(x). Guzik prawda, nie działa
> to. Również w sieci znalazłem informację, że domyślny separator plików
> CSV zapisany jest w rejestrze
> (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Text\Format) i
> rzeczywiście na moim komputerze jest tam ';'. Czyli wyglada na to, że
> rejestr bierze górę nad connectionstringiem i schema.ini.
>
> Czy ktoś udanie sparsował CSV przy pomocy OleDb i mógłby się podzielić
> doświadczeniami? Wszystkie wartości sa w " " ponieważ zawieraja
> przecinki (liczby).

A po co Ci do tego aż OleDb? Nie prościej napisać własny parserek lub 
nawet znaleźć w sieci gotowe DataReadery?

tm

> A po co Ci do tego aż OleDb? Nie prościej napisać własny parserek lub  
> nawet znaleźć w sieci gotowe DataReadery?
>
> tm

To wcale nie jest takie proste. Cudzysłowy w cudzysłowach, pola na wiele  
wierszy itd. A wczytanie tego to jest 1/10 całego zadania, więc średnio mi  
się uśmiecha pisanie pełnego parsera. Potrzebuję tego do komercyjnego  
produktu, więc nie mogę sobie ściągnąć z sieci.

zdefiniuj sobie szumi go wytnij lub zamień na jeden separator
-- 
pozdrawiam
robi

Użytkownik "3P" <nospam@serwer.pl> napisał w wiadomości grup 
dyskusyjnych:op.u71goheamsp0fz@mcs...
>> A po co Ci do tego aż OleDb? Nie prościej napisać własny parserek lub 
>> nawet znaleźć w sieci gotowe DataReadery?
>>
>> tm
>
> To wcale nie jest takie proste. Cudzysłowy w cudzysłowach, pola na wiele 
> wierszy itd. A wczytanie tego to jest 1/10 całego zadania, więc średnio mi 
> się uśmiecha pisanie pełnego parsera. Potrzebuję tego do komercyjnego 
> produktu, więc nie mogę sobie ściągnąć z sieci. 

W dniu 10-02-13 00:54, 3P pisze:
>> A po co Ci do tego aż OleDb? Nie prościej napisać własny parserek lub
>> nawet znaleźć w sieci gotowe DataReadery?
>>
> To wcale nie jest takie proste. Cudzysłowy w cudzysłowach, pola na wiele
> wierszy itd. A wczytanie tego to jest 1/10 całego zadania, więc średnio
> mi się uśmiecha pisanie pełnego parsera. Potrzebuję tego do komercyjnego
> produktu, więc nie mogę sobie ściągnąć z sieci.

Bzdura!

Mi znalezienie odpowiedniego parsera zajęło... 1 minutę! Szybki i na oko 
zgodny z RFC. Na licencji MIT, więc możesz użyć w komercyjnym produkcie.

http://www.codeproject.com/KB/database/CsvReader.aspx

Ile procent mi odpalisz ze swojego komercyjnego produktu? Zaoszczędziłem 
Ci trochę czasu ;)

tm

Dnia 13-02-2010 o 12:52:44 Tomasz Muszyński <thom_ek@op.pl_nospam>  
napisał(a):

> W dniu 10-02-13 00:54, 3P pisze:
>>> A po co Ci do tego aż OleDb? Nie prościej napisać własny parserek lub
>>> nawet znaleźć w sieci gotowe DataReadery?
>>>
>> To wcale nie jest takie proste. Cudzysłowy w cudzysłowach, pola na wiele
>> wierszy itd. A wczytanie tego to jest 1/10 całego zadania, więc średnio
>> mi się uśmiecha pisanie pełnego parsera. Potrzebuję tego do komercyjnego
>> produktu, więc nie mogę sobie ściągnąć z sieci.
>
> Bzdura!
>
> Mi znalezienie odpowiedniego parsera zajęło... 1 minutę! Szybki i na oko  
> zgodny z RFC. Na licencji MIT, więc możesz użyć w komercyjnym produkcie.
>
> http://www.codeproject.com/KB/database/CsvReader.aspx
>
> Ile procent mi odpalisz ze swojego komercyjnego produktu? Zaoszczędziłem  
> Ci trochę czasu ;)
>

Tylko że nie pasuje do obiektów w projekcie i musiałbym go sporo przerobić  
lub robić jakieś protezy. Poza tym trzeba umieszczać Copyright autora.
Pozostawię decyzję przełożonym, bo mogę zrobić nie uniwersalny parser  
(teraz i tak mam tylko jeden rodzaj CSV do parsowania).