Impossibile aprire altri database

zut

unread,

Jul 7, 2017, 8:26:46 AM7/7/17

to

Da cosa dipende questo tipo di errore?
Ho delle maschere aperte che sono originate da una query che filtra un'altra query che filtra un'altra query.
Troppe query a ricaduta possono generare questo errore?

zut

unread,

Jul 7, 2017, 9:25:07 AM7/7/17

to

In pratica ho una form parecchio complessa che mi riassume tutta una serie di dati relativi a delle aziende. Con doppio click sull'azienda mi si apre una form di dettaglio che provo a visualizzare come report e lì mi si intoppa perchè dei tre sottoreport me ne visualizza solo uno.
Provando ad aprire manualmente i sottoreport (con le form aperte) due di questi mi indicano "impossibile aprire altri database".
Se chiudo la prima form e riprovo, chiaramente mi chiede alcune date che erano presenti su quella maschera ma il report si apre perfettamente.
Devo OBBLIGATORIAMENTE semplificare tutte le query di origine della prima form?

GiorgioDaPrato

unread,

Jul 7, 2017, 12:09:48 PM7/7/17

to

> Devo OBBLIGATORIAMENTE semplificare tutte le query di origine della prima form?

non è specificato che l'applicazine sia in multiutenza (ma dovrebbe essere così) e nemmeno che FORSE l'origine dati dei vari report è posta "direttamente" sul BE

SE E' COSI' suggerisco di portare in locale (nel FE) TUTTE le origini di report e subreport (le query riempiono tabelle locali le quali sono poi le origini dati)

Personalmente adopero SEMPRE questa "soluzione" (dovrebbero esserci anche migliori prestazioni)

scaronic

unread,

Jul 10, 2017, 2:59:55 AM7/10/17

to

Ho avuto anch'io problemi simili, la prima soluzione è cercare di semplificare la catena di query a cascata . Ma se più di tanto non è possibile , l'unica soluzione che ho trovato e quella di generare ( o riempire ) una tabella temporanea di appoggio e poi leggerla all'apertura delle Forms e/o dei reports.

zut

unread,

Jul 10, 2017, 7:58:39 AM7/10/17

to

> SE E' COSI' suggerisco di portare in locale (nel FE) TUTTE le origini di report e subreport (le query riempiono tabelle locali le quali sono poi le origini dati)
>

Il db è in multiutenza e le query sono già tutte nel FE. Nel BE tengo solo e unicamente le tabelle

GiorgioDaPrato

unread,

Jul 10, 2017, 10:17:56 AM7/10/17

to

Il giorno lunedì 10 luglio 2017 13:58:39 UTC+2, zut ha scritto:
> > SE E' COSI' suggerisco di portare in locale (nel FE) TUTTE le origini di report e subreport (le query riempiono tabelle locali le quali sono poi le origini dati)
> >
> Il db è in multiutenza e le query sono già tutte nel FE. Nel BE tengo solo e unicamente le tabelle

non per fare il pignolo ma la precisazione che fai, di fatto NON precisa SE le origini di report e sottoreports sono o no su tabelle temporanee del FE, situazione che, come vedi anche dall'altra risposta, comporta differenza di prestazioni in casi come questo.

zut

unread,

Jul 11, 2017, 3:03:10 AM7/11/17

to

> non per fare il pignolo ma la precisazione che fai, di fatto NON precisa SE le origini di report e sottoreports sono o no su tabelle temporanee del FE, situazione che, come vedi anche dall'altra risposta, comporta differenza di prestazioni in casi come questo.

Chiedo scusa ma forse ho qualche lacuna io...
Sul BE ho tutte le tabelle del mio db mentre sul front ho tutte le query delle query delle query che sono all'origine dei miei report e sotto report.
Per tabelle temporanee suppongo che si intendano i recordset generati dalle query e in questo caso sono già sul FE.
Forse quello che mi porta via risorse è una query che ho "importato" da un altro db non mio che fa riferimento a tabelle che si trovano su quell'altro db. Non ho collegato tutte le tabelle esterne ma ho collegato solo la query con un
select * from AltroDB IN 'altro_percorso'
Grazie

GiorgioDaPrato

unread,

Jul 11, 2017, 4:20:28 AM7/11/17

to

intendo, per tabelle temporanee, (E locali) tabelle ottenute IN LOCALE (nel FE) come risultato di query di comando: query di creazione tabella oppure query di accodamento dati.

IN PRATICA: l'ultima query della serie (o una di quelle intermedie se già questa è troppo lenta) genera (query di creazione) oppure riempie (query di accodamento DOPO ovviamente aver svuotato i dati precedenti) la tabella.

La(e) tabella(e) diventa(no) origine(i) di report e subreport, o di quel subreport più impegnativo da ottenere

IN ALTERNATIVA: prova a fare questi passaggi SOLO con la query "importata"
(quindi: il risultato della query importata diventa una tabella temporanea con l'utilizzo di query di comando)

PERO' UNA COSA TI DEVE RESTARE AGEVOLE (E CHIARA):
se non hai mai utilizzato query di comando fai dei semplici esercizi di utilizzo,
poi per "chiamarle" da codice è sufficiente docmd.openquery nomeQuery

GiorgioDaPrato

unread,

Jul 11, 2017, 4:37:53 AM7/11/17

to

> Chiedo scusa ma forse ho qualche lacuna io...
> Sul BE ho tutte le tabelle del mio db mentre sul front ho tutte le query delle query delle query che sono all'origine dei miei report e sotto report.
> Per tabelle temporanee suppongo che si intendano i recordset generati dalle query e in questo caso sono già sul FE.
> Forse quello che mi porta via risorse è una query che ho "importato" da un altro db non mio che fa riferimento a tabelle che si trovano su quell'altro db. Non ho collegato tutte le tabelle esterne ma ho collegato solo la query con un
> select * from AltroDB IN 'altro_percorso'
> Grazie

AGGIUNTA:
IL SENSO del suggerimento è questo:
si "ferma" il set di dati in una tabella per "alleggerire" l'impegno del sistema quando l'oggetto che li deve utilizzare va in affanno, e ho indicato l'utilizzo di query di comando (che è una scelta possibile ...).

Ovviamente questo comporta una "scrittura supplementare", e quindi un impegno aggiuntivo del sistema, ma lo si fa con lo scopo (DA VERIFICARE DI VOLTA IN VOLTA) di eliminare un collo di bottiglia

Roberto Fabbri

unread,

Jul 11, 2017, 6:33:04 AM7/11/17

to

Il giorno martedì 11 luglio 2017 09:03:10 UTC+2, zut ha scritto:

Aspetta....hai collegato una query? Questo non si fa.....Tu hai diversi database, una query in un db che punta ad un'altro db, magari su macchine differenti pure. Secondo te qual'è il motore che risolve l'SQL? E' su un pc, mica è un deux ex machina!!!! Query, forms, report stanno sul FE. Sul BE (se parliamo di Access anche diversi BE ma SEMPRE SULLA STESSA MACCHINA, allora il motore è sempre lo stesso, ma quando vai in multiutenza avrai GROSSI PROBLEMI) le tabelle e basta. Il consiglio che ti hanno dato è: se l'elaborazione è troppo impegnativa, ti crei sul FE della tabella vuote, esegui le query iniziali e le riempi, poi elabori in locale. Niente traffico di rete (dopo l'elaborazione iniziale) e tutto sul pc locale. E' chiaro che i dati poi li devi sincronizzare