Newsgroup: it.comp.appl.access
Titolo: Quando piu' utenti accedono alle stesse tabelle

La mia applicazione prevede che l'utente scriva i dati in inserimento
e modifica in tabelle temporanee, poi da queste dopo i controlli i
dati vengono salvati nelle tabelle definitive. Il problema e' che
adesso l'applicaz dovra' essere usata da piu' utenti con tutti i
problemi che riguardano l'uso concorrente di piu' tabelle. Tutte le
form sono associate a tabelle sia in inserimento che in
modifica...come risolvere il problema?
In sintesi voglio evitare problemi di questo genere: un utente va in
modalita' inserimento e la form prende come source la tabella
temporanea ma gli appare il record in modifica di un altro utente che
in modalita' modifica ha messo quel record sempre nella stessa tabella
temp per modificarlo..
Si puo' fare in modo che Access possa creare piu' istanze utente
separate in scrittura e modifica su una stessa tabella?
Grazie.

 ha scritto:

io fossi in te farei tutte Form non associate (web style insomma)... la
cui "apertura" potrebbe interrogare un campo "cmp_RecordStatus" della
tabella di riferimento. Se lo stato risulta "IN LAVORAZIONE", "OCCUPATO",
"PRENOTATO" o quello che ti pare, avverti l'utente che non puo' usare quel
record e lo fai uscire, altrimenti lo fai entrare ponendo tu stesso
(quindi per quell'utente) il record nello stato di "IN LAVORAZIONE" (in
maniera tale che bloccare allo stesso modo chi prova ad entrare).
Ovviamente all'uscita, dovrai "SBLOCCARE" il record riportanto il
cmp_RecordStatus a "LIBERO"... in questo modo risolvi.
-- 
--------------------------------
Pablitomf
Napoli sempre nel "Q"uore!

 ha scritto nel messaggio 
news:d8c24e1d-cef0-4417...@k3g2000vbz.googlegroups.com...

Per ogni utente metterei una tabella temporanea.
Ognuno scrive liberamente. All'uscita o su "salva record" accodi i valori 
alla tabella principale, stabilendo tu l'ID da dare.
Al limite puoi riscrivere sulla tabella temporanea dell'utente, aggiornando 
il solo ID assegnato per quel record.
Ciao, Carlo 

 il solo ID assegnato per quel record.
Ok ma il problema e': come fa il codice a gestire ogni utente?
Esempio: utenti pippo pluto e paperino. Creo 3 tabelle
tbl_anag_temp_pippo, tbl_anag_temp_pluto ecc. A questo punto il codice
dovrebbe riconoscere ogni utente e dire "Ah tu sei pippo" e quindi
Form_anag.recordsource=tbl_anag_temp_pippo...ma come si fa riconoscere
gli utenti?

 ha scritto nel messaggio 
news:7d26bd5e-fac9-4b4e...@d7g2000vbv.googlegroups.com...

Se come immagino ad ogni utente hai dato un mde che si collega alle tabelle 
principali, non hai alcun problema.
Per esempio nella query di accodamento aggiungi semplicemente il nome 
dell'utente o il suo id.
Saprai sempre chi � l'utente.
Ovviamente hai anche creato un accesso per ogni utente, vero? Magari solo 
NomeUtente e Password da inserire all'apertura del db.
Se hai questo dato, capisci da solo, che � molto semplice.
Ciao, Carlo 

 ha scritto nel messaggionews:7d26bd5e-fac9-4b4e...@d7g2000vbv.googlegroups.com...

Forse può essere utile la funzione atCNames:
- atCNames(0) restituisce il nome del pc (la macchina).
- atCNames(1) il nome di log dell'utente.
Per il resto è ottima secondo me la soluzione di usare form non
associata, magari usando anche una transazione per aggiornare il
record.
Per form associata può essere utile il blocco di access a livello di
record?
Ciao a tutti
Sergio

 record?
Anche per me poteva andar bene fare form non associate ma un
cambiamento del genere comporterebbe il fatto di dover riscrivere
tutto il db dato che e' tutto basato sull'impianto di form associate.
La soluzione di Carlo mi sembra l'unica "fattibile" nell'immediato
anche se paghera' in chiave futura la mancanza di scalabilita' (se un
domani si aggiungono nuovi utenti devi di nuovo metter mano a codice e
tabelle).

 ha scritto nel messaggio 
news:f9abd634-7a21-412d...@a31g2000vbt.googlegroups.com...


-----------------------------
Ti basta una tabella UTENTI con appunto il campo Utente e magari un campo 
password.
Potrai aggiungere tutti gli utenti che vuoi.
All'apertura del db salvi in una tabella o in una variabile il nome utente.
Il resto è un gioco.
L'accodamento o salvataggio dei dati lo piloterai da un pulsante sulla 
maschera interessata.
Ciao, Carlo 

 Sergio
atCNames ??? su Access?

 atCNames ??? su Access?
Sì, eccola:
' USAGE: atCNames(1) =username
' USAGE: atCNames(2) =computername
Option Compare Database
Option Explicit
Private Declare Function api_GetUserName Lib "advapi32.dll" Alias 
"GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long
Private Declare Function api_GetComputerName Lib "kernel32" Alias 
"GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) As Long
Public GetUserName1 As String
Public Function atCNames(Us_Or_Cp As Integer) As String
'**************************************************
'Purpose: Returns the User LogOn Name or ComputerName
'Accepts: Us_Or_Cp; 1=User, anything else = computer
'Returns: The Windows Networking name of the user or computer
'**************************************************
On Error Resume Next
Dim NBuffer As String
Dim Buffsize As Long
Dim Wok As Long
Dim lR As Long
Dim sDump As String
Buffsize = 256
' NBuffer = Space(256)
NBuffer = Space$(Buffsize)
If Us_Or_Cp = 1 Then
    Wok = api_GetUserName(NBuffer, Buffsize)
    atCNames = Left$(NBuffer, InStr(NBuffer, Chr(0)) - 1)
Else
    Wok = api_GetComputerName(NBuffer, Buffsize)
    atCNames = Left$(NBuffer, InStr(NBuffer, Chr(0)) - 1)
End If
    sDump = String$(255, " ") 'Create a buffer
    lR = api_GetUserName(sDump, 255) 'Fill buffer with ID
    GetUserName1 = Left$(sDump, InStr(1, sDump, vbNullChar) - 1) 'Return 
just the id
End Function
Ciao, Carlo 

 Ciao, Carlo
Ok non e' la gestione degli utenti in se a preoccuparmi quanto il
fatto che il numero delle tabelle temporanee che posso prevedere e'
sempre legato al numero degli utenti.
Quindi dato che la mia applicaz deve memorizzare i dati di 6 entita'
finora ci sono 6 tabelle temp che sono associate alle varie form in
ins e modifica. Adesso che il db sara' usato da 4 persone dovro'
creare altre 6x3 tabelle temp per ciascun utente.
Facciamo il caso che tra 6 mesi si aggiungeranno altri 2
utenti..dovro' aggiungere altre 6x2 tabelle e aggiungere altri 2
case ai vari switch disseminati in tutte le routine....
Ripeto che questa e' la soluzione che adottero' ma i dubbi sul futuro
permangono.

 


 ha scritto nel messaggio 
news:4cffa30c-b128-4f8c...@z7g2000vbp.googlegroups.com...


--------------------------------------
Per come la vedo io se a te servono sei tabelle temporanee, queste 
rimarranno tali a prescindere dagli utenti.
Non hai più la necessità di nominare le tabelle con il postfisso NomeUtente 
(tbl_anag_temp_pippo, tbl_anag_temp_pluto) visto che ora sai sempre chi sta 
lavorando al db.
Al più dovrai aggiungere un solo campo alle tabelle (NomeUtente) temporanee. 
In fase di accodamento sarà il campo aggiunto a farti da guida.
Le tabelle temporanee sono presenti solo in locale, nell'mde 
dell'utente...Ora hai il nome utente che le usa, a che ti serve creare 
ulteriori  tabelle temporanee, quando dovrai aggiungere dei nuovi utenti?
Ciao, Carlo 


cut
Dimenticavo...Mi spieghi perchè hai bisogno di sei tabelle temporanee?
Che struttura hanno e dove devono essere accodate.
Ciao, Carlo