przykałd danych :
,2,ALAAAAA,Nazwa llala 5l,l,15,"136,18","2.042,70",23,"469,82","2.512,52"
Plik csv zawiera w pierwszej kolumnie ciąg znaków oddzielonych przecinkami,
coś w cudzysłowiu itd.
przykład danych : (oczywiście na górze są jakieś dane sprzedwacy itp, mało
istotne )
,2,ALAAAAA,Nazwa llala 5l,l,15,"136,18","2.042,70",23,"469,82","2.512,52"
W czym problem, poniższy kod pracuje niestabilnie - raz w
adoCSVRecordSet.Fields(0).Value wrzuca cały ciąg znaków na za chwilę na
innym pliku dzieli ten ciąg znaków.
Co jest nie tak z tym kodem ? jak inaczej można stabilnie importować plik
csv ?
'=====
Sub ImpCSV()
strPathToTextfile = "C:\Temp\CSV\"
' Specify CSV file name.
strCSVFile = "F144.csv"
' Open connection to the CSV file.
Set adoCSVConnection = CreateObject("ADODB.Connection")
Set adoCSVRecordSet = CreateObject("ADODB.Recordset")
' Open CSV file with header line.
adoCSVConnection.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & strPathToTextfile & ";" & _
"Extended Properties=""text;HDR=NO;FMT=Delimited"""
adoCSVRecordSet.Open "SELECT * FROM " & strCSVFile, adoCSVConnection
' Read the CSV file.
Do Until adoCSVRecordSet.EOF
Debug.Print adoCSVRecordSet.Fields(0).Value
adoCSVRecordSet.MoveNext
Loop
' Clean up.
adoCSVRecordSet.Close
adoCSVConnection.Close
End Sub
> 2,ALAAAAA,Nazwa llala 5l,l,15,"136,18","2.042,70",23,"469,82","2.512,52"
A nie prosciej:
DoCmd.TransferText acImportDelim, "Moja", "Nowa", "C:\Plik.csv", False, ""?
Separator pól specyfikacji pliku tekstowego odpowiada separatorowi
dziesiętnemu lub ogranicznikowi tekstu. error 3441.
:(
P.B.
Problem jest taki, ze:
- najpierw musisz utworzyc schemat (w tym przypadku nazywa sie 'Moja')
w tej specyfikacji okreslic separator dziesietny jako kropke,
a ogranicznik pola, jako przecinek,
- po zaimportowaniu wykonac kod, ktory zamieni kropke na "" (puste).
Masz bowiem taki zapis:
"2.042,70"
A wiec kwalifikatorem tekstu jest cudzyslow, separatorem pol przecinek, a
separatorem dziesietnym przecinek.
W takim przypadku "2.042,70" zostanie zamieniona na 2.042,70.
Wystarczy zamienic kropke na nic "" i bedzie ok.
Jezeli w obliczeniach bedziesz mial bledy, to przy konwersji uzyj VAL().
Pozdrawiam.
>> Mam kod jak poniżej, który powinien importować dokumenty z plików CSV.
>> WSZYSTKIE są identyczne struktura - różnica dotyczy ilości danych.
>>
>> przykałd danych :
>> ,2,ALAAAAA,Nazwa llala 5l,l,15,"136,18","2.042,70",23,"469,82","2.512,52"
>>
>>
>> Plik csv zawiera w pierwszej kolumnie ciąg znaków oddzielonych
>> przecinkami, coś w cudzysłowiu itd.
>> W czym problem, poniższy kod pracuje niestabilnie - raz w
>> adoCSVRecordSet.Fields(0).Value wrzuca cały ciąg znaków na za chwilę na
>> innym pliku dzieli ten ciąg znaków.
>>
>> Co jest nie tak z tym kodem ? jak inaczej można stabilnie importować
>> plik csv ?
ciach!
Po pierwsze niespecjalnie rozumiem tę waszą manię do używania ADO/ADOX.
Chyba że kod pisany jest nie spod access'a tylko w niezależnym programie.
Access powrócił do DAO i w zasadzie, pomijając małe wyjątki, ADO nie dość że
niczego fajnego nie wniosło, to jeszcze przy okazji wiele zabrało.
Wracają do meritum...
Twój ciąg znaków jest problemowy i myślę, że ma prawo powodować głupienie
sterownika ISAM.
Masz przecinki jako separatory pól ale i jako znak separatora dziesiętnego.
Do tego kropka jako separator tysięcy. No i czy zawsze w każdej linijce jest
ta sama ilość danych?
Mając na uwadze wszystkie te wątpliwości ja bym plik zassał (import,
linkowanie lub otwarcie recordsetu w kodzie) jako plik stałej (!!!)
szerokości, z jednym polem długości np. 1000 znaków.
Zabawę zacząłbym od stworzenia odpowiedniej specyfikacji, podlinkowania przy
jej pomocy pliku.
A potem można się bawić w recordsety i samodzielne parsowanie zawartości.
Na koniec, gdy obecność podlinkowanej tabeli już Ci się znudzi, można
wywalić ją i, pod obecność ciągle zapisanej specyfikacji, stworzyć recordset
w kodzie w oparciu o następujący SQL:
Select *
FROM [Text;DSN=Spec1;FMT=Fixed;HDR=NO;IMEX=2;DATABASE=C:\sciezka].[plik#txt]
Zaś jeszcze czyściej i bez żadnej specyfikacji:
Otworzyć w kodzie plik przy pomocy insrukcji:
OPEN ... FOR IMPUT
i czytać w pętli linijka po linijce...
SQL jest o tyle fajny, że można sobie wszystko w accessie na bieżąco
pooglądać w tabeli czy kwerendzie...
Ale potem jest już raczej zbędny.
--
KN