Jak w VBA importować z poziomu Accessa tabele lub kwerendy z Oracla do Accessa
sa...@gazeta.pl
Pobieranie danych z Oracla do Accessa można zrobić ręcznie za pomocą
menu "Pobierz dane zewnętrzne".
Ale jak to zrobić w kodzie VBA ?
Na razie doszedłem do tego:
Dim conn As ADODB.Connection
Set conn = New ADODB.Connection
conn.ConnectionString = "Provider=MSDAORA;DRIVER={Microsoft ODBC for
ORACLE};User ID=xxxxx;Password=xxxxx;Data Source=xxxxxx"
conn.Open
Wykonując to krokowo to widać, że do tego miejsca jest OK.
Potem:
Dim cmd As New ADODB.Command
strSQL = "Select * From Tabela1" - może tu jest źle ?
cmd.ActiveConnection = conn
cmd.CommandType = adCmdText
cmd.CommandText = strSQL
cmd.Execute
Ale to nic nie daje. W Accessie nie pojawia się żądana tabela.
I teraz mam problem, bo nie wiem co dalej. W literaturze jest dużo
różnych przypadków, ale nic mi na razie nie pasuje.
Przemysław Rachwał
przez plikowe ODBC
linkujesz prawoklikiem
sa...@gazeta.pl
> podlinkuj przez odbc - jest najpro�ciej, jak wolisz mo�na podlinkowa�
> przez plikowe ODBC
>
> linkujesz prawoklikiem
Czy to linkowanie - nie wiem za bardzo co to oznacza w tym wypadku -
potrzebne jest do nawiązania połączenia z Oraclem ? Jeżeli tak, to u
mnie jest OK.
Mogę, np. utworzyć kwerendę przekazującą, która zrzuca do Accessa
tabelę z bazy Oracle.
Mogę też czytać rekord po rekordzie (kolejne pola) z takiej tabeli
Oracla poprzez Debug.Print z (ogólnie) Recordset.
Ale chodzi mi o takie komendy VBA, które zaimportują tabelę z Oracla -
tak, jak można to zrobić "na piechotę" poprzez menu Accessa "Plik" -
"Pobierz dane zewnętrzne".
Oczywiście, w ostateczności można stworzyć odpowiednią ilość kwerend
przekazujących oraz odpowiadające im kwerendy tworzące tabele i
wstawić je do kodu jako DoCmd.OpenQuery .
Pozdrawiam
Andrzej
Przemysław Rachwał
"Plik" - "Pobierz dane zewnętrzne" - połącz tabele -> ODBC Databases
tu wybierasz odpowiedni DSN, jak nie masz to sobie robisz guzikiem
jak już się połączysz to wybierasz tabelkę lub perspektywę
pojawi się taka wirtualna tabelka - można z niej korzystać jak ze
zwykłej tabeli
sa...@gazeta.pl
>
> "Plik" - "Pobierz dane zewnętrzne" - połącz tabele -> ODBC Databases
>
>
> tu wybierasz odpowiedni DSN, jak nie masz to sobie robisz guzikiem
>
> jak już się połączysz to wybierasz tabelkę lub perspektywę
>
> pojawi się taka wirtualna tabelka - można z niej korzystać jak ze
> zwykłej tabeli
Widzę, że się nie rozumiemy.
Przecież wyraźnie napisałem, że potrafię się połączyć z bazą Oracle, w
tym w/w sposób.
Andrzej
Przemysław Rachwał
nie da się na robić jakieś protezy typu:
Dim conn As ADODB.Connection
Dim aRs as adodb.Recordset
Set conn = New ADODB.Connection
conn.ConnectionString = "Provider=MSDAORA;DRIVER={Microsoft ODBC for
ORACLE};User ID=xxxxx;Password=xxxxx;Data Source=xxxxxx"
conn.Open
Wykonując to krokowo to widać, że do tego miejsca jest OK.
Potem:
Dim cmd As New ADODB.Command
strSQL = "Select * From Tabela1" - może tu jest źle ?
cmd.ActiveConnection = conn
cmd.CommandType = adCmdText
cmd.CommandText = strSQL
set aRs = cmd.Execute
while not aRs.Eof
' tu dodaj rekord do tabeli w dowolny sposób
aRs.MoveNext
wend
cmd.execute bez instrukcji set nadaje się np. do robienia UPDATE
w takich konstrukcjach operujesz recordsetami i ADO a te mają się nijak
do DAO - enginu Access-a
Darek_K
> s...@gazeta.pl pisze:
>
> - Pokaż cytowany tekst -
ADO bez problemu działa z Accessem od wersji 2000
Jeżeli chcesz przepisywać dane Recordsetami - nie ma problemu - robisz
jeden na tabeli Oracle a drugi na Accessie i w pętli przepisujesz. Ale
to jest wolne. Dużo lepiej podlinkować tabelki Oraclowe i działać na
nich kwerendami tworzącymi tabele w Acc. Kwerendy jak wiesz można
odpalac z poziomu kodu
Pozdrawiam
DK
Przemysław Rachwał
wiem o tym, problem w tym że pytanie które padło na samym początku i tok
rozumowania powiedzmy to było mało sensowne z punktu widzenia Access-a -
chodzi o mieszanie ADO z obiekatmi typu tabela
fakt można sobie odpalić przedstawiony fragment kodu i coś zrobić, tyle
że to nie o to chodzi
rozwiązaniem problemów to DoCmd.TransferDatabase
> Jeżeli chcesz przepisywać dane Recordsetami - nie ma problemu - robisz
> jeden na tabeli Oracle a drugi na Accessie i w pętli przepisujesz. Ale
> to jest wolne. Dużo lepiej podlinkować tabelki Oraclowe i działać na
> nich kwerendami tworzącymi tabele w Acc. Kwerendy jak wiesz można
> odpalac z poziomu kodu
no wiem o tym
Przemysław Rachwał
http://www.knowledge-database.org/grp/pl_-comp_-bazy-danych_-msaccess_l641.html
http://www.techonthenet.com/access/modules/link_table.php
to chyba rozwiąże problem programowania importu danych
sa...@gazeta.pl
Cieszę się, że temat znalazł kolejnego dyskutanta.
Widzę, że podane propozycje podążają w oczekiwanym dla mnie kierunku.
Wypróbuję wkrótce, zaproponowany przez Przemka,
DoCmd.TransferDatabase. Przy okazji, podziękowania za linki odnośnie
importu danych.
Ale mam też prośbę do Darka odnośnie tekstu "Dużo lepiej podlinkować
tabelki Oraclowe i działać na
nich kwerendami tworzącymi tabele w Acc."
Czy masz na myśli kwerendy przekazujące ? Jeżeli nie, to co ? Napisz,
proszę, przykładowy fragment kodu.
Ja stosuję obecnie - z poziomu Accessa - kwerendy przekazujące i idące
za nimi kwerendy tworzące tabele z tych kwerend przekazujących.
Dziękuję i pozdrawiam
Andrzej
Krzysztof Naworyta
<cyte>
</cyte>
ufff, w międzyczasie powstał straaasznie długi wątek, a trafienia w sedno
jakby niewiele ;-)
Chcesz po prostu stworzyć acccessową tabelę w oparciu o dane z bazy Oracle ?
Uruchamiasz prostą kwerendę tworzącą tabelę:
Select * Into DocelowaTabelka
From
[ODBC;{ciąg połączenia do bazy
Oracle};Database=...;uid=...;pwd=...].TabelaŹródłowa
Z poziomu kodu:
CurrentDb.Execute "Select * Into DocelowaTabelka From [....].TabelaŹródłowa"
albo
CurrentProject.Execute ...
Inaczej wygląda sprawa z łączeniem tabel z Oracle (czy jakiegokolwiek innego
serwera)
Należy np. via DAO utworzyć odpowiedni obiekt TableDef, ustawić jego
właściwość Connect i dołączyć do kolekcji Database.TableDefs
Więcej znajdziesz w helpie pod CreateTableDef i Connect.
(nieco inaczej robi się to via ADO, ale i to da się wygooglać ;-) )
Odpowiednie akcje access'a pomagają pójść z tymi sprawami nieco na skróty.
I tu słusznie Przemek napomknął o DoCmd.TransferDatabase (gdzie odpowiedni
argument określa czy będzie to import, eksport czy po prostu stworzenie
linku)
Tabele połączone, to tak naprawdę "linki" do tabel oryginalnych.
Taki obiekt w accessie zawiera odpowiedni ciąg połączenia, dodatkowo access
buforuje informacje o polach tabeli i ich typach, indeksach itd.
W przypadku prostych zapytań czy połączeń z innymi tabelami tej samej
zdalnej bazy, access (a w zasadzie jego silnik) potrafi przekazać właściwe
zlecenie do serwera i pobrać zwrotną informację, w niemal tak samo efektywny
sposób, jakby pracował na swoich tabelach lokalnych.
Gorzej w przypadku kiedy nie potrafi stwierdzić co powinien przekazać do
servera a co wyliczyć u siebie, z już przejętych wyników.
W takich sytuacjach lepsze są kweredy przekazujące, które w ogóle pomijają
silnik Jet, i całą składnię zapytania wysyłają wprost do serwera.
Jednak dla akcji tworzenia tabeli w oparciu o prosty warunek na polu
indeksowanym, prosta kwerenda oparta na tabeli połączonej będzie wymagała
prawdopodobnie dużo mniej zachodu, niż tworzenie kwerendy przekazującej, by
dopiero w oparciu o nią tworzyć docelową kwerendę tworzącą tabelę ...
--
KN
sa...@gazeta.pl
Dzięki za podpowiedź i za podsumowanie tematu.
Pozdrawiam
Andrzej
Aleksander Lipiec
Kidyś robiłem coś podobnego więc postaram się podać receptę w skrócie:
Za pomocą ADO tworzę tabelę z polami o określonym typie ( jak w helpie )
Otwieram połączenie za pomocą ADO (jak w helpie)
Uruchamiam zapytanie i kopuję dane do tabeli też ADO (jak w helpie)
Ważny jest typ pól do których kopiujesz dane!
Na pewno wszystko działa.
Powodzenia
P.S.
Czy twoja aplikacja w AC. to fronton a zaplecze to MSDE albo MSSQLSERV ?
Jeżeli tak to można stworzyć procedurę która zrobi to wszysko za ciebie.
Hej
--
Archiwum grupy: http://niusy.onet.pl/pl.comp.bazy-danych.msaccess