Newsgroup: it.comp.appl.access
Titolo: Eseguire SP con ADO..!

Scusate la domanda stupida, ma č poco che
sono costretto ad ADO, e mi da qualche dubbio.
Nel senso che con A97 per eseguire SP usavo Qry_PT
delle quali cambiavo la proprietą SQL.
Ora non aveno a disposizione, almeno credo, con
ADP questo tipo di QRY mi vieneil dubbio di dover eseguire
un comando SQL con l'equivalente Execute di DAO...!
Di fatto dovrei stabilire una Connection dinamica ed usare
il metodo Command "EXEC sp_MyaSP" quindi tutto il resto.
Di fatto pongo la domanda come conferma sulla metodologia, o come
consulenza per un metodo migliore.
Saluti.
@Alex.


Ciao @Alex
Con la premessa che non saprei se è il metodo migliore ti posto la funzione
che utilizzo per eseguire una Sp o una qualsiasi query (aggiornamento,
accodamento, selezione) o un qualsiasi comando Tsql.
Per eseguire una Sp : Exec "EXEC NomeSp parametro1,Parametro2,ecc"
Per eseguire un comando Tsql : Ecex "DBCC SHRINKDATABASE('NomeDb')"
Per eseguire un "Dlookup" o un Dmax o  una qualsiasi query che deve rendere
un risultato:
  Debug.print Exec("Select Top1 Nome campo FROM.. ecc ec'")
  Debug.print Exec("Select COUNT(DISTINCT NomeCampo) FROM ecc,ecc")
o conoscere la versione di SqlServer Debug.print Exec("Select @@VERSION")
Pe eseguire una query di aggiornamento Exec "UPDATE Tabella SET ecc. ecc."
Insomma ci faccio tutto, l'unica limitazione della funzione è il non poter
leggere i parametri di Output delle Sp,  in questo caso devi utilizzare
l'insieme Parameters dell'oggetto command (personalmente non uso Sp con
OutParam e comunico eventuali messaggi tramite una Select).
Ciao Giorgio.
==================================
'Esegue una Stringa Sql e rende il Primo Campo
Function Exec(ByVal Sqltext As String) As Variant
    Dim Rs As ADODB.Recordset
    Dim Comm As ADODB.Command
    Dim Result As Variant
    On Local Error GoTo ExecSql_Err
    Set Comm = New ADODB.Command
    Comm.CommandType = adCmdText
    Comm.CommandText = Sqltext
    Comm.ActiveConnection = CurrentProject.Connection
    Comm.CommandTimeout = 0  'Infinito
    Set Rs = Comm.Execute
    Result = ""
    'Se esiste il recordset rendo il primo field
    If Rs.State <> 0 Then
       If Rs.EOF = False Then
          Result = Rs.Fields(0)
       End If
    End If
    Set Rs = Nothing
    Set Comm = Nothing
    Exec = Nz(Result)
ExecSql_Fine:
Exit Function
ExecSql_Err:
MsgBox Error
Exec = "'ERROR'"
Resume ExecSql_Fine
End Function
==================================

 ha scritto nel messaggio
news:bmtpji$4dk$1...@lacerta.tiscalinet.it...

Ciao Giorgio, si hai confermato in effetti quello che pensavo, razzolando
nell'Help non avevo trovato altro metodo per farlo, di conseguenza per me
era l'unico....!
Sei stato molto cortese a fornirmi una Funzione già fatta, che avrei dovuto
farmi, quindi a buon rendere.
Sinceramente non mi piace moltissimo ADO, ma noto con piacere la potenza
di ADP.
Con A97 si hanno limitazioni enormi lavorando solo con Tabelle allegate,
mentre con ADP ti togli ogni limte, o quasi.
Ci stò giocando perchè mi hanno chiesto un gestionale in questa direzione
ma se fosse per le mie esigenze con i vincoli che ho al lavoro SQL_Server7.0
e Office97 non mi muoverei di molto.....!
P.S. in che caso ti torna utile recuperare come hai fatto il 1° Record....??
In effetti io avrei pensato di controllare solo EOF e BOF e restituire un
Boolean
ma visto che arriva da chi lo usa ne consegue che è utile, solo non ci
arrivo..!
Grazie mille.
@Alex.

 arrivo..!
Ciao @Alex
Il ritorno del primo campo relativo al primo record mi torna utile quando
utilizzo la funzione al posto di Dlookup, in questo modo ho il vantaggio di
non essere legato al parametro "Dominio" ,  ad esempio con DlookUp non
potresti fare una cosa del genere
=================
MioControllo=
       Exec("SELECT SUM(R.Importo)
                  FROM Fatture F INNER JOIN
                               Fatture_Righe R ON F.Id_Fat=R.Id_Fat
                  WHERE F.CodiceCli=1")
================
Ciao Giorgio


MMmmmmm....!
Ottimo, in effetto ho riletto bene il tuo post, e mi era venuta l'idea, ma
l'esempio che mi hai fatto è lampante.
Ho già provato ed in effetti è estremamente comodo.
Ho provato la rapidità rispetto al Dsum e devo dire che già su un Db
con 25000 Records si nota...!
Arigrazie.
Buon Week-End
@Alex.

 Arigrazie.
Ragazzi, dato il vostro entusiasmo per gli .ADP, posso esporvi un
"problemino" che ne limita pesantemente l'utilizzo con Access 'XP (e solo
quello, col 2000 va tutto a meraviglia)?
... alla faccia delle buone prestazioni...

 ha scritto nel messaggio
news:J0Ckb.51282$e6.18...@twister2.libero.it...

Si spara pure.
@Alex.

 mentre con ADP ti togli ogni limte, o quasi.
Aspetta prima di cantar vittoria ...sul ng. Yankee ricordo un motto del
genere:
"ADPs: how to workaround today?"
:-)

 Si spara pure.
Beh, in pratica convertendo un mese fa un vecchio ADP 2000 a 'XP ho sbattuto
la faccia contro una situazione sconfortante:
Maschera continua con poche migliaia di records (non ditemi che è un
approccio Client-Server scorretto o chiudiamo subito il TH e torno al RPG).
Imposto un criterio Orderby sulla form _anche su campi indicizzati_ ... beh,
il tutto diventa di una lentezza esasperante.
Con Access '2000 .ADP tutto ok.
Bye

 il tutto diventa di una lentezza esasperante.
Dimenticavo: ho provato di tutto per aggirare (how to workaround today?); ho
impostato a codice il recordset lato Client, lato Server, di tutto ... senza
apprezzare miglioramenti.
Uno dei punti di forza di Access è l'estrema praticità di un'interfaccia che
consente a qualunque stupido utente d'impostare filtri e ordinamenti su
qualunque campo (naturalmente avevo creato menù di scelta rapida opzionali
con queste features).
Ma se gli ordinamenti, di fatto, sono inutilizzabili...
Bye

 ha scritto nel messaggio
news:h4Ckb.49338$vO5.1...@twister1.libero.it...

Si, non sto cantando "Winning Time", ma non essendo novellino
le differenze dal mio buon vecchio A97_SQLServer le vedo in fretta.
Tieni poi presente che tutto quello che riuscivo a fare prima lo so
fare anche ora.....!
Poi sono un pò masochista, quindi amo farmi del male, se invece sarete
voi ad infliggermi il coltello nella piaga...... godrò un pò meno, ma
è il bello della diretta.
Ciao.
@Alex.

 fare anche ora.....!
Sicuro, sicuro?
Tanto per cominciare (eh, eh: vai col quiz): come fai a gestire temporanei
locali legati al client con gli ADP?
Bye

 ha scritto nel messaggio
news:8hCkb.49369$vO5.1...@twister1.libero.it...

La risposta te la sei praticamente già data, ma per non farti scappare in
effetti
la cosa è quantomeno strana.
Hai provato invece di usare OrderBy a sfruttare il Recordset di Form per
paragone
ed ordinare su quello.....!
Io non ho A2K, non è vero, ma non lo uso avendo XP che già mi piace poco.
Il bello della conversione di alcuni lavori da A97 a AXP sono i bellissimi
colori
delle Maschere, e dei controlli trasparenti che hanno sfumature di Grigio
diverse.
Ma dico io MS no poteva lasciarle =......!
@Alex.

 ha scritto nel messaggio
news:YrCkb.51352$e6.18...@twister2.libero.it...

Bella, ma sei bastardo dentro....!
Risposta:
Con Recordset locali....??
Ciao.
@Alex.

 ha scritto nel messaggio
news:zxCkb.51370$e6.18...@twister2.libero.it...

Solo A97--SQL_Server(via ODBC-Direct con Query PT per quasi tutto) ne sono
obbligato dalla modernità aziendale alla quale mi adeguo ed obbedisco.
Solo da poco (1 settimana) ho iniziato con ADP per motivi personali, ma
tieni conto che il mio lavoro
è tutt'altro che realizzare programmi.....!
@Alex.

 Con Recordset locali....??
La questione è interessante: non ti è mai capitato di dover generare un
Report
di grande complessità e trovar comodo (o necessario) lavorare su un
temporaneo locale da impostare come origine dati del suddetto?
Dove volevo arrivare è come generare temporanei legati all'utente sul
Server.
Tuttavia, credo che sia praticabile anche la tua idea (ma solo con A 'XP):
utilizzare un recordset ADO direttamente in memoria _si può_ e provare ad
assegnarlo a runtime con l'apposito oggetto al Report.
Proverò...
Bye

 è tutt'altro che realizzare programmi.....!
Ma ... ADP con A '2000 o 'XP?
Bye

 ha scritto nel messaggio
news:6_Ckb.51473$e6.18...@twister2.libero.it...

Vedi che il vecchio qualche volta ci pensa...!
Con A97 è uno scherzo, per questo ti dicevo...!
Ciao.
@Alex.

 ha scritto nel messaggio
news:__Ckb.51474$e6.18...@twister2.libero.it...

A2002 che dicono sia XP.... ma che genera Mdb(2000) da convertire in 2002 se
vuoi creare MDE_XP.....!
La MS mi fa impazzire con tutte queste cose.........!!!!
@Alex.

 ha scritto nel messaggio
news:YrCkb.51352$e6.18...@twister2.libero.it...

Ciao Randagio
Con SqlServer puoi creare tabelle temporanee (quelle che iniziano con #)
direttamente sul server, farci quello che vuoi e restituire il recordset a
un report o a una form ,  non devi neanche preoccuparti a eliminare la
tabella perché ci pensa il server quando il batch è terminato.
Tutto il lavoro viene eseguito sul server senza intasare la rete.
Esempio
==============
CRAETE PROCEDURE Proc1
AS
SET NOCOUNT ON
CREATE TABLE  #Tb1 (Campo1,cc ecc)
INSERT #Tb1 SELECT .... FROM  Tab1
INSERT #Tb1 SELECT .... FROM  Tab2
UPDATE #Tb1 Set ...
SELECT * FROM #Tb1
=============
Ciao Giorgio

 ha scritto nel messaggio
news:8hCkb.49369$vO5.1...@twister1.libero.it...

Ciao Randagio,
è vero questo è uno dei BUG di AccessXp con i progetti ADP, personalmente
non lavoro con maschere continue, ma essendo un BUG implementato nella
versione 2002 penso che MS lo risolva insieme ad altri bug più noiosi come
il non liberare la memoria dopo aver chiuso un Form o un report.
Articolo Microsoft Knowledge Base - 331989
ACC2002: Memory Is Not Released When You Close Forms and Reports
http://support.microsoft.com/default.aspx?scid=kb;en-us;331989
Ciao Giorgio

 >
Dimenticavo...
La tebella temporanea (con un solo #) esiste solo per il batch in esecuzione
quindi più di un utente può eseguire la Sp nello stesso istante.
Cerca sul manuale in linea CREATE TABLE troverai maggiori informazioni.
Ciao Giorgio

 
http://support.microsoft.com/default.aspx?scid=kb;en-us;331989
Ciao Giorgio:  speriamo bene :-)
Bye

 Cerca sul manuale in linea CREATE TABLE troverai maggiori informazioni.
Mah, in realtà ho già spulciato da tempo queste cose (grazie anche alla kb)
... la mia era una domanda cattivella per Alessandro!
Per me arrivare a creare temporanei sul Server a richiesto tempo, denaro e
seccature (anche perchè non è proprio una soluzione da manuale).
Ciao!

 Per me arrivare a creare temporanei sul Server
a richiesto tempo, denaro e
HA richiesto!!


Ciao Randagio
In SqlServer le tabelle temporanee vengono create sul database TempDb,
questo database č utilizzato anche dal motore del db per creare "tabelle
temporanee" necessarie alla determinare delle query con GROUP BY ORDER BY e
UNION, inoltre il loro utilizzo puň rendere piů veloce l'esecuzione di una
query complicata. Oltre alla tabella temporanea (che inizia con #) esiste
anche il tipo di dati TABLE
==================
DECLARE @Tb1 TABLE
  (Campo1 int,
   Campo2 int)
INSERT @Tb1 VALUES(1,2)
SELECT * FROM @Tb1
==================
che č consigliata se viene utilizzata con pochi record (ad esempio per
totalizzare il fatturato mensile e il progressivo, 12 record).
Come portai vedere nel manuale ci sono molti riferimenti alle tabelle
temporanee, il loro utilizzo puň impegnare il server ma l'operazione č
sempre piů veloce che caricare il recordset in una tabella locale.
Ciao Giorgio


Assolutamente sì ma parliamo di una lista con tipo recordset  snapshot non
aggiornabile, con poche colonne e basso numero di record (5  o 6 Mila),
dipende tutto da quanti Kb Access deve memorizzare  (in genere se stai sotto
a 1 Mb non ci sono rallentamenti) . In altro caso puoi sempre paginare o
applicare dei filtri sul server (ServerFilter), cosa consigliata per reti a
bassa velocità.
Ciao Giorgio

 sempre più veloce che caricare il recordset in una tabella locale.
Ti ringrazio per le informazioni  ;-)
Ciao!

 bassa velocità.
Beh, ma è proprio il caso a cui mi rifacevo.
Evinco quindi che non consenti ai tuoi utenti di modificare i criteri
d'ordinamento nella vista tabellare ... diversamente ti tirerebbero il collo
(con A 'XP) ;-)
Bye

 ha scritto nel messaggio
news:LWPkb.52573$e6.18...@twister2.libero.it...

Sarai anche cattivello, ma ti ho spiazzato....!
Da inesperto quale sono ti ho dato una risposta che anche Giorgio
mi ha confermato almeno a livello di praticità.
Il vecchio, ce ne
vuole........................................................
Saluti.
@Alex.

 Il vecchio, ce ne
E' no: la risposta di Giorgio verte sui temporanei creati sul Server _che
utilizzo in questi casi senza troppa soddisfazione_.
Il tuo post mi ha dato un'idea nuova, comunque inattuabile con A '2000
(richiede il passaggio a Runtime di un recordset come origine dati del
Report).
Bye


Ciao
(Scusa questo post me lo ero perso)
Torno a ripetere che per viste tabellari con pochi record e che occupano
poca memoria non c'è problema a modificare i criteri di ordinamento, per
quanto riguarda le tabelle con grossi volumi di dati (Ordini Fatture ecc)
impongo dei filtri (mese , cliente , Nonevaso ecc), secondo me non ha senso
visualizzare (ad esempio) la lista di tutti gli ordini, può essere comoda ma
richiede il trasferimento di tutti i record dal server al client e  la
memorizzazione da parte del client in uno snapshot locale (con i problemi
che ne derivano).
Insomma... non si può utilizzare SqlServer pensando che sia un database di
Access,  tanto vale mantenere Access e JET che a livello di computer desktop
è molto veloce ma messo in rete è un disastro in affidabilità (è soggetto a:
problemi di rete, problemi di client  -memoria disco- ,  problemi di
operatore che quando è in panico spegne il computer ecc ecc) e per quanto
riguarda la velocità è deludente.
Ben venga la sistemazione di questi problemi ma tieni presente che
utilizzando una rete a bassa velocità (VPN ecc) ti ritorneranno tutti.
Ciao Giorgio


Ciao Randagio
Vorrei capire la tua riluttanza sull'utilizzo dei temporanei creati sul
server, a questo proposito ti propongo una semplice Stored procedure e mi
piacerebbe sapere che cosa non ti soddisfa.
================================
CREATE PROCEDURE usp_RapportoMensile
AS
SET NOCOUNT ON
-- Tabella temporanea
CREATE TABLE #TotMesi
   (Mese smallint,
    Fatturato numeric(18,2) DEFAULT 0,
    ProgFatturato numeric(18,2) DEFAULT 0,
    Ordinato numeric(18,2) DEFAULT 0,
    ProgOrdinato numeric(18,2) DEFAULT 0
  )
-- Inserisco i 12 mesi
DECLARE @Mese smallint
SET @Mese=1
WHILE @Mese<=12 BEGIN
     INSERT #TotMesi (Mese) VALUES(@Mese)
     SET @Mese=@Mese+1
END
-- Inserisco il fatturato mensile
UPDATE Tot
   SET Fatturato=TotMese
FROM
  #TotMesi Tot INNER JOIN
  (Select Month(Data) Mese,
          Sum(Importo) TotMese
   FROM Fatture GROUP BY MONTH(Data)
   ) F
   ON F.Mese=Tot.Mese
-- Inserisco l'ordinato mensile
UPDATE Tot
   SET Ordinato=TotMese
FROM
  #TotMesi Tot INNER JOIN
  (Select Month(Data) Mese,
          Sum(Importo) TotMese
   FROM Ordini GROUP BY MONTH(Data)
   ) O
   ON O.Mese=Tot.Mese
-- Calcolo i progressivi
UPDATE Tot
   SET ProgFatturato=(SELECT SUM(fatturato)
                      FROM #TotMesi Tot1
                      WHERE Tot1.Mese<=Tot.Mese),
       ProgOrdinato =(SELECT SUM(Ordinato)
                      FROM #TotMesi Tot1
                      WHERE Tot1.Mese<=Tot.Mese)
FROM #TotMesi Tot
-- Rendo l'output
SELECT * FROM #TotMesi
==============================
Ciao Giorgio.

 utilizzando una rete a bassa velocità (VPN ecc) ti ritorneranno tutti.
Le installazioni remote preferiamo gestirle con servizi Terminal Server.
Ciao!

 piacerebbe sapere che cosa non ti soddisfa.
Spesso si è scritto su areee pubbliche (e in passato esistevano dubbi
amletici anche su questa), che sia una soluzione sporca (se preferisci una
porcata) forzare un server SQL a creare/distruggere temporanei.
Sono stato influenzato da tale "corrente" e li utilizzavo di malavoglia.
Tuttavia, leggendo il tuo post dell'altro dì, intravedo la faccenda in modo
diverso e al più presto approfondirò la faccenda con i books online.
Quindi più che insoddisfatto (funzionano benone) ero ... poco convinto.
Bye