Newsgroup: it.comp.appl.access
Titolo: Stored procedures con join aggiornabili

Avrei bisogno di creare delle stored procedures che pescano i dati da più
tabelle in join e che consentano di aggiungere delle righe. Se c'è una
tabella sola non c'è problema, ma se c'è un join sia le procedure che le
funzioni diventano in sola lettura. Con le view che invece sono sempre
dinamiche (quando è possibile) non posso specificare dei parametri...
C'è un modo di aggirare il problema? (per il momento cambio al volo il
rowsource della maschera mettendoci la query per esteso costruita via Vb...)

 dinamiche (quando č possibile) non posso specificare dei parametri...
Non mi risulta.
Se usi la stessa istruzione sql in una vista o in una sp ottieni lo stesso
risultato di aggiornabilita' o meno.
ferse nella sp hai dimenticato di inserire la chiame primaria.
Sib

 risultato di aggiornabilita' o meno.
E' quello che pensavo anch'io. La query proviene da una view (che era
aggiornabile), ed è stata copiata pari pari nella sp, dove nella clausola
WHERE al posto di una costante ho messo un parametro. La sp non è
aggiornabile. Le chiavi ci sono di tutte le tabelle coinvolte. Non cambia
niente a togliere del tutto Where e parametro. Togliendo tutte le tabelle in
join e lasciandone una sola torna aggiornabile. Aggiungendo anche una sola
join diventa in sola lettura. Inner, Outer o Cross poco importa (provate
tutte...)
Addirittura se creo una funzione con la stessa query la visualizzazione in
Access è quella dei recordset aggiornabili (con l'ultima riga vuota con
l'*), ma se provo a scriverci quando poi mi sposto o cerco di chiudere
ottengo un avviso di sola lettura! :-/
Non è neanche una questione di permessi, dato che sia dbo che sa gli utenti
normali autorizzati ottengono lo stesso trattamento...

 ha scritto nel messaggio
news:qB4Ua.24407$sj6.5...@tornado.fastwebnet.it...

Confermo quanto detto da il Gatto
Ciao Giorgio.

 > "Sib" <si...@SPAMiol.it> ha scritto nel messaggio

Sara', pero a me questo codice SQL:
--------
SELECT Anagrafica.IDCliente, Anagrafica.RagioneSociale,
Anagrafica.Via, Anagrafica.CAP, Anagrafica.Città,
Anagrafica.Provincia, Anagrafica.Prefisso, Anagrafica.Telefono,
Attrezzi.IDModello, Attrezzi.Descrizione, Attrezzi.Matricola,
Attrezzi.VersioneStrumento, Attrezzi.DataInst,
Attrezzi.DataVendita, Attrezzi.IDAttrezzo
FROM dbo.Anagrafica INNER JOIN
dbo.Attrezzi ON
dbo.Anagrafica.IDCliente = dbo.Attrezzi.IDCliente
--------------
Sia inserito in una SP sia in una vista mi risulta sempre perfettamente
aggiornabile.
Sib


Ciao Sib
E' molto interessante quello che affermi. Premetto che non utilizzo mai
query di questo tipo per l'origine record di una maschera che ha lo scopo di
inserire o variare i dati ma sono molto curioso e ti propongo di fare una
prova con dei parametri comuni a tutti.
Da Access fai click sull'help, scegli Database di esempio-->Progetto di
esempio NorthWind.
Nella sezione Query c'è una vista con nome "Orders Qry" che è origine record
del Form Orders. Le tabelle contenute nella vista sono Customers in
relazione uno a molti con Orders e collegate con una INNER JOIN
-----------------------------
dbo.Customers INNER JOIN  dbo.Orders ON
dbo.Customers.CustomerID = dbo.Orders.CustomerID
------------------------------
Prova a copiare il codice Sql della vista "Orders Qry"  in una Sp quindi
apri l'Sp.
A me viene reso un recordset non aggiornabile mentre la vista è
aggiornabile.
E a Te?
Ciao Giorgio.

 E a Te?
Si parlava di usarle all'interno di maschere e impostata come recordsource
di una mashera la SP con codice copiaincollato da Orders Qry mi risulta
perfettamente aggiornabile.
Non e' che avete dimenticato di impostare la proprieta' "Tabella Univoca"
nella maschera?
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:ZOcUa.14601$Df5.3...@news1.tin.it...

Ciao Sib
Cosa intendi per Sp ?
Ciao Giorgio

 >
Ciao Sib
Una Stored Procedure è un oggetto del database come le tabelle le viste gli
indici ecc..
Una Stored Procedure è un gruppo di istruzioni Transact-SQL compilate in un
singolo piano di esecuzione, piano di esecuzione riutilizzabile ogni
qualvolta che la si richiama. Per utilizzare una Stored Procedure  come
origine record di una maschera devi inserire il nome della Sp nella
proprietà origine record e puoi passare i parametri ad essa compilando la
proprietà Parametri di input della maschera stessa.
Ovviamente a te funziona non usi una Stored Procedure ma un comando SQL che
deve essere compilato ed eseguito al momento.
Per maggiori informazioni puoi consultare il Book On Line di Sqlserver
ricercando Stored Procedure quindi selezionando la voce Panoramica.
Ciao Giorgio

 ha scritto nel messaggio
news:DqaTa.20548$sj6.4...@tornado.fastwebnet.it...

Ciao Il Gatto
Se i parametri da passare servono a filtrare i dati della form, pur
mantenendo la vista come origine record puoi agire sulla proprietà
ServerFilter, esempio
Me.ServerFilter="Codice >=1000"
Me.Requery
Naturalmente non ha le stesse potenzialità della Stored Procedure ma penso
sia meglio che ricomporre la stringa SQL .
Ciao Giorgio

 ricercando Stored Procedure quindi selezionando la voce Panoramica.
Lo faro' certamente, ma a prescindere da cio' che dice, e' certo che la sp
come origine record di una maschera e' aggiornabile (a patto di definire la
tabella univoca e, ovviamente, a patto che sia concettualmente aggiornabile
come codice SQL).
Perche', tu vuoi dire che da te non risulta aggiornabile?
Sib


Ciao Sib
Scusa ho frainteso il tuo post
Aprendo direttamente la sp dalla finestra query risulta in sola lettura.
Aprendo la maschera che ha come origine record la il nome sella Sp fa finta
di essere aggiornabile ma al primo inserimento record dà errore 1029  'Il
valore della chiave è stato eliminato dall'archivio dati'
La tabella univoca è compilata in questo caso con orders come per la vista.
Non capisco, forse è una questione di versione dei drivers ADO OLEDB o forse
c'è qualche altro paramentro da impostare, come ti ho preannunciato non
utilizzo mai origini record con Join per inserimenti o variazioni.
Ciao Giorgio

 utilizzo mai origini record con Join per inserimenti o variazioni.
Ciao
Sib

 sia meglio che ricomporre la stringa SQL .
In effetti alla fine ho fatto così. Grazie!
Ah! Ho provato come suggeriva Sib ad impostare la proprietà di tabella
univoca, ma come dici tu salta fuori il messaggio d'errore. Però il record
viene salvato,
contrariamente a quello che Access sostiene!
Purtroppo però anche intercettando gli errori di runtime da Vb non si può (o
meglio io non ci sono riuscito) impedire che venga visualizzato almeno il
messaggio "Si è verificato un errore composto da più passaggi, ecc...", nè
evitare che sulla riga compaia un #Eliminato molto poco convincente.

 ha scritto nel messaggio
news:%h6Va.26829$sj6.5...@tornado.fastwebnet.it...

Ciao Il Gatto
Questo mi solleva molto, cominciavo a pensare di avere problemi hardware o
software.
Ciao Giorgio.

 evitare che sulla riga compaia un #Eliminato molto poco convincente.
Premesso che non è una soluzione pulita: hai provato a disabilitare la
gestione errori interna di Access?
Evento "Su Errore":   response=acdataerrcontinue

 Evento "Su Errore":   response=acdataerrcontinue
Sì, ma così sono riuscito solo ad evitare il messaggio di chiave
modificata/cancellata, non quello di Errore composto da più passaggi (che
compare prima di generare l'evento, a quanto pare...), inoltre la maschera
dopo l'insert funziona in modo un po' strano (tornando indietro di un record
comparivano alcuni campi vuoti, e chiudendo la maschera immancabile l'avviso
"impossibile salvare l'oggetto" -  In realtà già salvato!! Boh!??)....
Può darsi che si possa risolvere la cosa scrivendosi a manina il
ResyncCommand, ma adesso non ho tempo di farlo, inoltre non ho ben capito se
il R.C. viene invocato solo per l'update - che funziona benissimo - o anche
per l'insert che fa 'ste cose strane...

 evitare che sulla riga compaia un #Eliminato molto poco convincente.
A questo punto sono io che comincio a pensare di avere una versione
taroccata.
Non solo non mi ha mai dato alcun tipo di errore, non solo, al contrario,
sono le viste filtrate a darmi errore (vedi in proposito miei post
precedenti su messaggio "Record aggiunto ma non visualizzato perche non
corrisponde ai criteri", falsita' perche' corrispondeva), ma fin'ora non mi
ero mai posto il problema se una maschera era legata a una sp o a una vista,
quindi per sapere quante delle mie maschere sono collegate a una sp dovrei
controllarle una a una.
Sib

"Sib" <si...@SPAMiol.it> ha scritto nel messaggio
news:iq7Va.23099$Df5.6...@news1.tin.it...

Ciao
Secondo me il tutto si spiega con le diverse versioni di Access, sib ha
Access2000 io ho AccessXp.
Un'altra differenza tra le due versioni (o un bug implementato con Xp)  è
con i campi calcolati, se questi eccedono dalla precisione 28,x  Xp non li
interpreta correttamente e li visualizza come stringa 125.25000000,
Access2000 li visualizza bene 125,25
Ciao Giorgio.

 Access2000 io ho AccessXp.
Mi sa che č proprio cosě, anch'io uso Access Xp, ottenendo risultati
(toppati) in accordo con te e in disaccordo con Sib.
Perň dato che in giro ho anche Access 2000 mi sa che se trovo un po' di
tempo qualche esperimento lo faccio, anche se dato che il problema
sembrerebbe presentarsi sulla versione piů recente invece che su quella
vecchia (che a quanto pare funzionava, grazie M$: quale bug vuoi aggiungere
oggi?) in prospettiva mi adeguo a considerarla come una limitazione sempre
presente... X-(

 Access2000 li visualizza bene 125,25
Di questo non mi sono mai accorto, come dicevo nell'altro 3d, io normalmente
lavoro con XP, e' solo da un cliente che sono PURTROPPO costretto a usare
2000.
Immagino che tu abbia gia' scaricato tutti gli ultimi service pack.
Indaghero'.
Ciao
Sib

 (toppati) in accordo con te e in disaccordo con Sib.
Non posso concordare del tutto.
Sia con SQL Server 2000 sia con SQL Server 7 il comportamento che ottengo e'
lo stesso, con le sp aggiornamento e aggiunta funziona tranne che per
l'aggiunta viene visualizzato un messaggio che dice che il record e' stato
inserito ma non viene visualizzato perche' non corrisponde ai criteri (anche
se invece corrisponde) e in effetti chiudendo e riaprendo la maschera il
record c'e'.
Questo, come dicevo, vale per tutte e due le versioni di SQL.
Provero' con XP stasera appena arrivo a casa.
cut
Comunque ho perso un po' di vista il problema iniziale, perche' avevi
necessita' di usare sp al posto di viste se poi usavi lo stesso codice SQL?
Sib

 necessita' di usare sp al posto di viste se poi usavi lo stesso codice
SQL?
Il programma che ho per le mani è stato scritto con Access 97 (e DAO) e lo
sto portando su Xp/Sql server, con notevole rottura di scatole
(nell'originale si fa un uso smodato di tabelle locali - per fortuna nessuna
indispensabile, query nidificate a 5 livelli con dozzine di clausole WHERE
del tipo ClienteID=[forms]![clienti]![ClienteID], oppure cose tipo SELECT
Funzione_VB_Lunga_130_righe([Campo]) AS Totale...)
Alcune maschere usano un recordset pescato tramite join per ordinare l'unica
tabella che viene aggiornata secondo i valori di un campo dell'altra (nella
quale non si scrive niente, serve solo ad ordinarla). Contemporaneamente la
maschera ha bisogno di essere filtrata su parametro (un valore prelevato da
una combo di un'altra maschera), quindi ho usato una sp, e qui sono
cominciati i guai.
Per non saper nè leggere nè scrivere ho aggirato in prima istanza il
problema impostando il rowsource su OnOpen via Vb, impostando i parametri co
me costanti, in seguito - come suggeritomi - usando una normale view (che
non da alcun problema!!) e impostando il filtro sul server, così mi
risparmio anche diverse seccature per quello che riguarda la manutenzione e
il risultato è soddisfacente.
A questo punto la mia era più che altro una curiosità, giusto per sapere se
si tratta di una limitazione (o di un bug, o che altro) o se sono incapace
io (cosa tuttaltro che improbabile) e quindi l'occasione per imparare
qualcosa di nuovo... :-)

 qualcosa di nuovo... :-)
Stasera ti diro'.
Ciao
Sib

 utilizzo mai origini record con Join per inserimenti o variazioni.
Non so dirti...
Ciao
Sib

 rowsource della maschera mettendoci la query per esteso costruita via
Vb...)
Casomai ce ne fosse stato bisogno, e' confermato che AXP tratta le sp come
dicevi tu, ossia come se fossero oggetti non aggiornabili e dando una serie
di msgbox sballate che mentono spudoratamente.
La cosa piu' strana e' che A2000 (versione che ritengo nettamente inferiore
ad AXP) invece si limita ad un timido messaggio "quasi" corretto, come
dicevo nell'altro post.
eppure non mi e' del tutto chiaro questo discorso, tanto piu' che AXP, a
differenza di A2000, consente perfino la creazione guidata di maschere
basate su sp e quindi, in teoria, dovrebbe amministrarle meglio.
ad ogni modo, cosi' e'.
Ciao
Sib