Newsgroup: it.comp.appl.access
Titolo: tabelle temporanee in MSDE sql server

Ho quasi effettuato il porting della mia applicazione in SQL server. Mi 
resta un grosso dubbio in merito alla creazione di tabelle temporanee.
Al momento mi collego via odbc, per cui posso mantenere in locale le tabelle 
temporanee che popolavo periodicamente nel momento in cui all'utente 
occorreva fare modifiche a determinati records solo x un suo utilizzo 
temporaneo. (nello specifico la selezione dei nominativi per la stampa delle 
etichette. Creo la temporanea perchè nello stesso momento un altro client 
può selezionare o modificare gli stessi nominativi di un altro)
Se passassi ai progetti adp e non avessi più le tabelle native di access 
(jet) come potrei gestire le tabelle temporanee??? Dovrei crearne, sul 
server una per ogni client che desidera effettuare operazione di selezione 
record diverse dagli altri? 


Ciao ciroteo,
potresti ad esempio creare una sola tabella aggiungendo un campo che
identifica l'utente che ha fatto  la selezione e poi filtrare di
conseguenza.
Per avere l'ID del processo che ADP corrente ti puň essere utile questa
query:
SELECT     @@SPID AS ID, SYSTEM_USER AS [Login Name], USER AS [User Name]
Dal BOL:
@@SPID Restituisce l'identificatore (ID) del processo server per il processo
utente corrente.
Ciao
Cinzia


hmhm... ho capito. In sostanza creo una tabella temporanea con il campo che 
identifica il processo/utente. Accodo i records,  l'utente 
seleziona/modifica e alla fine elimina solo quelli associati al suo 
identificativo di processo ... arguta!
A questo punto dovrei far selezionare i record dalla tbl base e 
contemporaneamente accodare questi dati e il dato relativo al processo nella 
tabella temporanea. Si tratta di due query ... sarà che con una stored 
procedure si possono fare entrambe in un colpo solo?

 ha scritto nel messaggio
news:dg3u55$mcv$1...@hulme.interac.it...

Certo che si, ancor meglio forse  in un trigger INSTEAD OF UPDATE, in fondo
a te non serve aggiornare il campo (così è sempre pronto x gli altri utenti)
(invece di aggiornare il campo di selezione, metti l'ID del record
selezionato e lo @@SPID  nella tabella di selezione)
Ciao
Cinzia

 record diverse dagli altri?
Prima di prendere in considerazione gli .ADP ti consiglio di provarli bene:
potresti avere sgradite sorprese rispetto a connessioni ODBC.
Ciao.


Dal libro Transact-SQL Programmazione avanzata:
Creazione di tabelle temporanee locali
Le tabelle che cominciano per # sono locali alla sessione in cui sono state
create. non sono visibili in nessun'altra sessione, nemmeno in quelle che
fanno parte dello stesso host o dello stesso login.Ciň significa che alcune
sessioni possono creare una tabella temp locale servendosi tutti dello
stesso nome senza danneggiarsi a  vicenda.
Le tabbelle che cominciano per ## sono globali e quindi visibili a tutti gli
utenti che si connettono. Quindi č possibile creare una sola tabella globale
con lo stesso nome.
Ho utilizzato le tabele locali # senza incontrare ancora alcun problema. Se
vuoi visualizzare la Temp devi utilizzare Query Analyzer. Visualizza la
cartella tempdb di sql e la sottocartella  TabelleUtenti.
Ciao
Fabio

 ha scritto nel messaggio 
news:dg5pev$o94$1...@area.cu.mi.it...

grazie fabio  .. cercherň info in questa direzione.

 ha scritto nel 
messaggio news:_fgVe.59976$HM1.1...@twister1.libero.it...

Al momento uso odbc, e l'adp lo uso per modifiche a tabelle e prove con sp 
...

 Al momento uso odbc, e l'adp lo uso per modifiche a tabelle e prove con sp
Ho capito, ma t'invito a provarli bene onde evitare sorprese di cui poi ti
potresti pentire.
Gli .ADP, strutturalmente, non possone prevedere features come le specifiche
d'importazione e la connettività a fonti dati diverse da MS SQL Server.
Nel caso tu dovessi  interfacciarti ad altre origini dati dovresti creare
"server collegati" lato Server ... ma che (attualmente) funzionano a sola
lettura.
Occhio quindi: in varie situazioni la cosa potrebbe crearti grossi problemi.
Inoltre t'invito a provare il funzionamento delle Forms di un ADP quando
connesse a recordsets relativamente grossi: prestazioni di caricamento dati
dal Server inaccettabili e problemi di funzionamento con filtri/ordinamenti
a Runtime.
Questo soprattutto in merito alle versioni XP e 2003 di Access.
E' vero che in modalità Client-Server si deve cercare di trattare recordset
"piccoli", ma non puoi impedire all'utente di operare diversamente se lo
desidera.
Per contro in questi casi le tabelle collegate ODBC lavorano in maniera
molto intelligente (e puoi usare il profiler per capire come) restituendo al
client solo la pagina di dati a video (a meno di cliccare sul pulsante
"ultimo record").
Quindi ripeto l'invito: non fidarti delle "brochures pubblicitarie" e
confronta bene le due configurazioni.
a)   2  PC in rete
b)   Un DB sul Server SQL con qualche tabella (generata a codice) con una
milionata di record(s)
c)   Profiler o analizzatore di rete per vedere come viaggiano i pacchetti
dal Server al Client.
Ciao.