Dobry sposób na brak kontroli, problem z połaczeniem to nie tylko jego wyłaczenie...
Ale tu masz kod który ponawia połaczenie co 20 minut:
On Error Resume next
conStr= "DSN=xxxx;UID=yyyy;;"
Set DB = CreateObject("ADODB.Connection")
'Połącz z serwerem
db.open conStr
'Jeżeli nie masz połaczenia, nawiązuj je co 20 minut
Do Until db.State=1
WScript.Sleep 1200000
db.open conStr
Loop
'Reszta kodu
@Panczo: Dzięki, chwilę zajęło testowanie, oczywiście działa rewelacyjnie, od kiedy użyłem tej części kodu nie zdarzyły się puste tabele i dokładnie widać, o której się napełniają przez co dane dostępne są zdecydowanie wcześniej.
Znowu wracam do tematu, po aktualizacji office z 2010 na 365 skrypt przestał działać, komunikat jak poniżej .
Plik się otwiera, kwerendy usuwające działają.
connStr = "Provider=Microsoft.ACE.OLEDB.12.0; Data Source="
Set objConn = CreateObject("ADODB.Connection")
'Set objDelFil= CreateObject("Scripting.FileSystemObject")
'objDelFil.DeleteFile("C:\Users\Documents\tabele_prognozy\_95\*.laccdb")
'AKTUALIZACJA DANYCH W PLIKU #1
plik = "C:\Users\Documents\tabele_prognozy\_95\_95_tabela_moje_kody.accdb"
'otwieram polaczenie
objConn.open connStr & plik
with objConn
.Execute "01_czysci_tabela_moje_kody"
.Execute "02_aktualizuje_tabela_moje_kody"
end with
objConn.Close
compactACCDB plik
WScript.Sleep 3000
a pobierające dane już nie.
Jeżeli ręcznie otworzę plik bazy danych i z "kliknięć" kwerendy działają i pobierają się bez problemu. Ktoś ma jakiś pomysł, co się mogło stać?
Dzięki i pozdrawiam.
Bez kodu kwrendy to wróżenie z fusów...
literał kwerendy się nie zmienił, jak otwieram plik bazy ms access i uruchamiam kwerendę "z palca" to wszystko się pobiera prawidłowo. Struktura katalogów bez zmian, komputer ten sam, jedyne, co się zmieniło to Office 2010 na 365. System 64bity Office też 64.
INSERT INTO 00_tabela_moje_kody ( A_C_FRS, A_C_8MTI, A_DESCRIPTION, A_MARQUE, A_STATUT, EI_C_EAN, CC_C_REFERENC, A_C_CONSO, A_DATE_SUP, A_NBJ_MIN_DVL, A_NBJ_SECURITE, [DLA BAZY], PAKOWANIE, WARSTWA, ILE_WARSTW, PALETA )
SELECT G253DOGI_ARTICLES.A_C_FRS, G253DOGI_ARTICLES.A_C_8MTI, G253DOGI_ARTICLES.A_DESCRIPTION, G253DOGI_ARTICLES.A_MARQUE, G253DOGI_ARTICLES.A_STATUT, G253DOGI_EAN13_8MTI.EI_C_EAN, G253DOGI_CODE_CONSO.CC_C_REFERENC, G253DOGI_ARTICLES.A_C_CONSO, G253DOGI_ARTICLES.A_DATE_SUP, G253DOGI_ARTICLES.A_NBJ_MIN_DVL, G253DOGI_ARTICLES.A_NBJ_SECURITE, ([A_NBJ_MIN_DVL]-[A_NBJ_SECURITE]) AS [DLA BAZY], G253DOGI_ARTICLES.A_CDT_FRS_A AS PAKOWANIE, G253DOGI_ARTICLES.A_CDT_FRS_B AS WARSTWA, G253DOGI_ARTICLES.A_CDT_FRS_C AS ILE_WARSTW, ([A_CDT_FRS_B]*[A_CDT_FRS_C])*1 AS PALETA
FROM G253DOGI_EAN13_8MTI INNER JOIN (G253DOGI_CODE_CONSO INNER JOIN G253DOGI_ARTICLES ON (G253DOGI_CODE_CONSO.CC_C_FRS = G253DOGI_ARTICLES.A_C_FRS) AND (G253DOGI_CODE_CONSO.CC_C_CONSO = G253DOGI_ARTICLES.A_C_CONSO)) ON G253DOGI_EAN13_8MTI.EI_C_8MTI = G253DOGI_ARTICLES.A_C_8MTI
WHERE (((G253DOGI_CODE_CONSO.CC_C_REFERENC)="F01") AND ((G253DOGI_ARTICLES.A_DATE_SUP)>#1/1/2019#) AND ((G253DOGI_EAN13_8MTI.EI_ORDRE)=1));
Zacząłbym od użycia ACE w wersji 16
sprawdzałem, niestety nic nie zmieniło. Ale z plikiem się łączy, bo tworzy plik tymczasowy i kwerendę usuwającą uruchamia.
To nie mam za bardzo pojecia, co jest nie tak,
A puszczenie sql zadziała:
sql = "INSERT INTO 00_tabela_moje_kody ( A_C_FRS, A_C_8MTI, A_DESCRIPTION, A_MARQUE, A_STATUT, EI_C_EAN, CC_C_REFERENC, A_C_CONSO, A_DATE_SUP, A_NBJ_MIN_DVL, A_NBJ_SECURITE, [DLA BAZY], PAKOWANIE, WARSTWA, ILE_WARSTW, PALETA ) " & _
"SELECT G253DOGI_ARTICLES.A_C_FRS, G253DOGI_ARTICLES.A_C_8MTI, G253DOGI_ARTICLES.A_DESCRIPTION, G253DOGI_ARTICLES.A_MARQUE, G253DOGI_ARTICLES.A_STATUT, G253DOGI_EAN13_8MTI.EI_C_EAN, G253DOGI_CODE_CONSO.CC_C_REFERENC, G253DOGI_ARTICLES.A_C_CONSO, G253DOGI_ARTICLES.A_DATE_SUP, G253DOGI_ARTICLES.A_NBJ_MIN_DVL, G253DOGI_ARTICLES.A_NBJ_SECURITE, ([A_NBJ_MIN_DVL]-[A_NBJ_SECURITE]) AS [DLA BAZY], G253DOGI_ARTICLES.A_CDT_FRS_A AS PAKOWANIE, G253DOGI_ARTICLES.A_CDT_FRS_B AS WARSTWA, G253DOGI_ARTICLES.A_CDT_FRS_C AS ILE_WARSTW, ([A_CDT_FRS_B]*[A_CDT_FRS_C])*1 AS PALETA " & _
"FROM G253DOGI_EAN13_8MTI INNER JOIN (G253DOGI_CODE_CONSO INNER JOIN G253DOGI_ARTICLES ON (G253DOGI_CODE_CONSO.CC_C_FRS = G253DOGI_ARTICLES.A_C_FRS) AND (G253DOGI_CODE_CONSO.CC_C_CONSO = G253DOGI_ARTICLES.A_C_CONSO)) ON G253DOGI_EAN13_8MTI.EI_C_8MTI = G253DOGI_ARTICLES.A_C_8MTI " & _
"WHERE (((G253DOGI_CODE_CONSO.CC_C_REFERENC)='F01') AND ((G253DOGI_ARTICLES.A_DATE_SUP)>#1/1/2019#) AND ((G253DOGI_EAN13_8MTI.EI_ORDRE)=1));"
.Execute sql
dostaje komunikat jak na grafice. Zastanawiam się czy nie jest coś namieszane ze sterownikami bazy.
Czytałeś w ogóle komunikat, który dostałeś?
To jest błąd kompilacji, czyli ze składnią coś nie tak.
tak, czytałem, zmieniałem cudzysłów/średnik czy inne znaki i nic. Wspomniałem o sterowniku w kontekście poprzedniego komunikatu. Szukam innego sposobu lub/i w całości będę migrował na ms sql server.
Zmianie mozna by poddać tę linijke
"WHERE (((G253DOGI_CODE_CONSO.CC_C_REFERENC)='F01') AND ((G253DOGI_ARTICLES.A_DATE_SUP)>#1/1/2019#) AND ((G253DOGI_EAN13_8MTI.EI_ORDRE)=1));"
na
"WHERE (((G253DOGI_CODE_CONSO.CC_C_REFERENC)=""F01"") AND ((G253DOGI_ARTICLES.A_DATE_SUP)>#1/1/2019#) AND ((G253DOGI_EAN13_8MTI.EI_ORDRE)=1));"
Ale ciągle nie pokazujesz błędu związanego z zapytaniem.
tak, po zmianie składni wywala błąd źródła odbc. Natomiast jak normalnie otworzę plik access i kliknę kwerendy to idą i kończą poprawnie
tylko spójrz, skrypt wcześniej sprawdza połączenie i przechodzi.
'Połącz z serwerem
db.open conStr
'Jeżeli nie masz połaczenia, nawiązuj je co 15 minut
Do Until db.State=1
WScript.Sleep 900000
db.open conStr
Loop
Wygląda na to, że sterownik oracle jest 32bit. Jest możliwość, że access sobie z tym radzi, a sam system bez otwartego pliku bazy już nie?
Masz w tym insercie select do 3 tabel:
Rozumiem, że są to tabele połączone?
tak, w access przez odbc do oracle "połącz ze źródłem danych, tworząc tabelę połączoną"
Nie wiem jak access rozróżnia czy jest otwarty i czy ma to wpływ na bitowość używanego sterownika ODBC.
Ustaliłbym tylko, czy vbs który odpalasz, odpalasz jako 32 czy 64 bit?
Zrezygnowałbym z linkowania tabel do oracle, na rzecz 1 kwerendy przekazującaj dane (join po stronie tabel linkowanych sprawia, że pobierasz całą zawrtość tych tabel do siebie)
Doinstalował 64 bitowe sterowniki do oracle
i zobaczył czy to zacznie działać
VBS na 100% uruchamia się jako 64bit, system win7 tez jest 64. Na innych komputerach, gdzie office2010 jest 32 bytowy skrypty wcale nie chodziły.
jak będzie wyglądała składnia poniższej, żeby była przekazująca i czy typ kwerendy też muszę zmienić w access? Z tego co pamiętam przy tej zmianie trzeba jeszcze podać w ustawieniach string połączenia z hasłami i użytkownikami?
INSERT INTO 00_tabela_moje_kody ( A_C_FRS, A_C_8MTI, A_DESCRIPTION, A_MARQUE, A_STATUT, EI_C_EAN, CC_C_REFERENC, A_C_CONSO, A_DATE_SUP, A_NBJ_MIN_DVL, A_NBJ_SECURITE, [DLA BAZY], PAKOWANIE, WARSTWA, ILE_WARSTW, PALETA )
SELECT G253DOGI_ARTICLES.A_C_FRS, G253DOGI_ARTICLES.A_C_8MTI, G253DOGI_ARTICLES.A_DESCRIPTION, G253DOGI_ARTICLES.A_MARQUE, G253DOGI_ARTICLES.A_STATUT, G253DOGI_EAN13_8MTI.EI_C_EAN, G253DOGI_CODE_CONSO.CC_C_REFERENC, G253DOGI_ARTICLES.A_C_CONSO, G253DOGI_ARTICLES.A_DATE_SUP, G253DOGI_ARTICLES.A_NBJ_MIN_DVL, G253DOGI_ARTICLES.A_NBJ_SECURITE, ([A_NBJ_MIN_DVL]-[A_NBJ_SECURITE]) AS [DLA BAZY], G253DOGI_ARTICLES.A_CDT_FRS_A AS PAKOWANIE, G253DOGI_ARTICLES.A_CDT_FRS_B AS WARSTWA, G253DOGI_ARTICLES.A_CDT_FRS_C AS ILE_WARSTW, ([A_CDT_FRS_B]*[A_CDT_FRS_C])*1 AS PALETA
FROM G253DOGI_EAN13_8MTI INNER JOIN (G253DOGI_CODE_CONSO INNER JOIN G253DOGI_ARTICLES ON (G253DOGI_CODE_CONSO.CC_C_FRS = G253DOGI_ARTICLES.A_C_FRS) AND (G253DOGI_CODE_CONSO.CC_C_CONSO = G253DOGI_ARTICLES.A_C_CONSO)) ON G253DOGI_EAN13_8MTI.EI_C_8MTI = G253DOGI_ARTICLES.A_C_8MTI
WHERE (((G253DOGI_CODE_CONSO.CC_C_REFERENC)="F01") AND ((G253DOGI_ARTICLES.A_DATE_SUP)>#1/1/2019#) AND ((G253DOGI_EAN13_8MTI.EI_ORDRE)=1));
W kwerendzie przekazującej masz tylko select.
Później ja wykorzystujesz w kwerendzie.
Tak zmieniasz typ kwerendy i w arkuszu właściwości ustawiasz połączenie.