Tabella collegata via ODBC in Access : blocco dei record
Matteo Barsotti
Salve al tutto il ng,
In Access mi capita in alcune tabelle collegate via odbc che in fase di
modifica appare questo eloquente messaggio:
"durante la corrente sessione di modifica il record è stato modificato
da un altro utente ..."
[copia negli appunti] [non salvare le modifiche]
la cosa strana è che se apro la tabella con enterprise manager e provo a
modificare lo stesso record non da problemi.
Sembrerebbe un problema di access... ma se cancello la tabella odbc e la
riconnetto non cambia nulla.
Riavviando il servizio sql non cambia nulla.
A qualcuno è successo qualcosa di simile?
Questa è la tabella:
CREATE TABLE [Distinte_Parametri] (
[MODULO] [nvarchar] (10) COLLATE Latin1_General_CI_AS,
[NomeFileAnagrafica] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[NomeFileDatiSensibili] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[NomeFileDistinta] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[PasswordFileZip] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[IndirizzoEmail] [nvarchar] (100) COLLATE Latin1_General_CI_AS,
[OggettoEmail] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[MAPIUserName] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[MAPIPassword] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[SeparaPrestazioniPagate] [bit] DEFAULT 0,
[AzzeraPrestazioniPagate] [bit] DEFAULT 0,
[UsaCodiceMedicoRegionale] [bit] DEFAULT 0,
[CampoCodicePrestazione] [nvarchar] (30) COLLATE Latin1_General_CI_AS,
[SeparatoreDecimale] [nvarchar] (1) COLLATE Latin1_General_CI_AS,
[PercorsoFloppy] [nvarchar] (50) COLLATE Latin1_General_CI_AS,
[CalcolaRitenute] [bit] DEFAULT 0,
[UsaTariffeFebb2005] [bit] DEFAULT 0,
[InserisciCognomeNome] [bit] DEFAULT 0,
CONSTRAINT Distinte_Parametri_PrimaryKey PRIMARY KEY (MODULO)
) ON [PRIMARY];
Matteo
giorgio rancati
"Matteo Barsotti" <m.barsotti@cbsistemi_NO_SPAM_THANKS.it> ha scritto nel
messaggio news:d1u89p$qtk$1...@news.ngi.it...
>
> Salve al tutto il ng,
> In Access mi capita in alcune tabelle collegate via odbc che in fase di
> modifica appare questo eloquente messaggio:
>
> "durante la corrente sessione di modifica il record è stato modificato
> da un altro utente ..."
> [copia negli appunti] [non salvare le modifiche]
>
>
> la cosa strana è che se apro la tabella con enterprise manager e provo a
> modificare lo stesso record non da problemi.
> Sembrerebbe un problema di access... ma se cancello la tabella odbc e la
> riconnetto non cambia nulla.
> Riavviando il servizio sql non cambia nulla.
>
> A qualcuno è successo qualcosa di simile?
>
>
> Questa è la tabella:
>
Ciao Matteo,
strano, in genere l'errore si presenta in presenza di campi Bit a cui manca
il valore predefinito o di campi float.
Vedo dalla struttura della tua tabella che non è il tuo caso, comunque prova
ad aggiungere un campo timestamp
--------------
ALTER TABLE [Distinte_Parametri]
ADD timestamp
--------------
il campo timestamp in fase di Update evita al motore Jet di Access di fare
il confronto di tutti i campi della tabella , infatti utilizzerà solo la
Primary Key e il campo timestamp.
Alcuni riferimenti
-----------------
http://support.microsoft.com/default.aspx?scid=kb;en-us;278696&Product=acc97
http://support.microsoft.com/kb/280730/EN-US/
----------------
Ciao Giorgio
Matteo Barsotti
> [CUT]
> strano, in genere l'errore si presenta in presenza di campi Bit a cui manca
> il valore predefinito o di campi float.
> Vedo dalla struttura della tua tabella che non è il tuo caso, comunque prova
> ad aggiungere un campo timestamp
> --------------
> ALTER TABLE [Distinte_Parametri]
> ADD timestamp
> --------------
> il campo timestamp in fase di Update evita al motore Jet di Access di fare
> il confronto di tutti i campi della tabella , infatti utilizzerà solo la
> Primary Key e il campo timestamp.
> [CUT]
Hai ragione! Aggiunto il timestamp il problema svanisce.
Mi sei stato davveo utilissimo, grazie.
Secondo te è il caso di mettere un timestamp su tutte le tabelle?
Finora mi è accaduto solo in tabelle dove erano presenti campi di tipo
bit o ntext (memo), può bastare usare il timestamp solo su quelle?
Grazie ancora
ciao
Matteo
giorgio rancati
"Matteo Barsotti" <m.barsotti@cbsistemi_NO_SPAM_THANKS.it> ha scritto nel
[CUT]
>
> Hai ragione! Aggiunto il timestamp il problema svanisce.
> Mi sei stato davveo utilissimo, grazie.
>
> Secondo te è il caso di mettere un timestamp su tutte le tabelle?
> Finora mi è accaduto solo in tabelle dove erano presenti campi di tipo
> bit o ntext (memo), può bastare usare il timestamp solo su quelle?
a tua discrezione :-)
Personalmente lo inserisco se una tabella ha più di 3 campi.
Tieni presente che tale campo velocizza il comando di Update inviato da Jet
verso ODBC o (per i progetti ADP) inviato dal provider
*Microsoft.Access.OLEDB.xx.x* verso il data provider *SQLOLEDB*
La presenza del campo timestamp è indispensabile anche in presenza di
trigger che modificano uno o più campi della tabella.
> Grazie ancora
prego,
Ciao Giorgio
Jenga
> [CUT]
> >
> > Secondo te è il caso di mettere un timestamp su tutte le tabelle?
> > Finora mi è accaduto solo in tabelle dove erano presenti campi di tipo
> > bit o ntext (memo), può bastare usare il timestamp solo su quelle?
>
> a tua discrezione :-)
>
> Personalmente lo inserisco se una tabella ha più di 3 campi.
> Tieni presente che tale campo velocizza il comando di Update inviato da Jet
> verso ODBC o (per i progetti ADP) inviato dal provider
> *Microsoft.Access.OLEDB.xx.x* verso il data provider *SQLOLEDB*
> La presenza del campo timestamp è indispensabile anche in presenza di
> trigger che modificano uno o più campi della tabella.
>
Ho anche io spesso il problema segnalato da Matteo.
Le mie tabelle hanno molti campi float, ma la cosa strana è che NON succede
su tutte le tabelle.
I timestamp non sono usati da nessuna parte, ma le tabelle hanno un campo
DATAAGG che viene aggiornato da un trigger di insert/update con la data
dell'ultima modifica del record.
Potrebbe essere un problema?
Cosa intendi con "La presenza del campo timestamp
è indispensabile anche in presenza di
trigger che modificano uno o più campi della tabella." ??
Grazie
--
Se la giustizia ti giustizia
commette un ingiustizia
giorgio rancati
"Jenga" <ibru...@jumpy.it> ha scritto nel messaggio
news:20050325...@mynewsgate.net...[CUT]
>
> Ho anche io spesso il problema segnalato da Matteo.
> Le mie tabelle hanno molti campi float, ma la cosa strana è che NON
succede
> su tutte le tabelle.
> I timestamp non sono usati da nessuna parte, ma le tabelle hanno un campo
> DATAAGG che viene aggiornato da un trigger di insert/update con la data
> dell'ultima modifica del record.
>
> Potrebbe essere un problema?
> Cosa intendi con "La presenza del campo timestamp
> è indispensabile anche in presenza di
> trigger che modificano uno o più campi della tabella." ??
>
> Grazie
Ciao Jenga,
Sia il campo float che il trigger contribuiscono anche se con errori diversi
a generare il problema.
Il campo Float genera il problema esposto da Matteo
---------------
"durante la corrente sessione di modifica il record è stato modificato
da un altro utente ..."
[copia negli appunti] [non salvare le modifiche]
---------------
perchè in fase di Update può succedere che il valore del campo Float in
(presenza di decimali) non corrisponda al valore effettivo in tabella.
Questo caso è facilmente individuabile intercettando i comandi che arrivano
a Sql Server tramite il tool Profiler.
Per risolvere basta aggiungere un campo timestamp che evita il confronto di
tutte le colonne.
prova a creare una semplice tabella,
------------
Create Table Tab
(Id int identity(1,1) primary Key,
Campo1 varchar(50),
Campo3 Varchar(50),
Campo4 Int)
-------------
la alleghi ad access e inserisci queste 4 righe
---------------
Id Campo1 Campo3 Campo4
1 A1 B1 1
2 A2 B2 2
3 A3 B3 3
--------------
adesso modifica da access il valore di campo1 della prima riga da "A1" a
"AA1" e vedi cosa intercetta profiler
--------------
exec sp_executesql N'UPDATE "dbo"."Tab" SET "Campo1"=@P1 WHERE "Id" = @P2
AND "Campo1" = @P3 AND "Campo3" = @P4 AND "Campo4" = @P5', N'@P1
varchar(50),@P2 int,@P3 varchar(50),@P4 varchar(50),@P5 int', 'AA1', 1,
'A1', 'B1', 1
--------------
come puoi vedere la Where esegue il filtro su tutti i campi della tabella
*1, 'A1', 'B1', 1*
adesso aggiungi il campo timestamp
------------
Alter Table Tab
Add timestamp
------------
scollega e ricollega la tabella in access e ripeti l'update, ad esempio
sulla seconda riga. (Campo 1 da "A2" ad "AA2") , vedi cosa intercetta
profilrer
------------
exec sp_executesql N'UPDATE "dbo"."Tab" SET "Campo1"=@P1 WHERE "Id" = @P2
AND "timestamp" = @P3', N'@P1 varchar(50),@P2 int,@P3 binary(8)', 'AA2', 2,
0x000000000000014C
------------
come puoi vedere la Where esegue il filtro solo sulla primary key e sul
campo timestamp, tutti gli altri campi *float inclusi* non servono perchè se
la where trova il record (quindi il valore in timestamp non è cambiato)
siamo sicuri che nessun'altro ha modificato il record.
Il caso del trigger che modifica uno o più campi è più difficile da
individuare ed è un problema completamente diverso.
L'errore si presenta *Prima* di modificare il record con questo messaggio
---------------------
I dati sono stati modificati
Prima di salvare le modifiche ai dati, un altro utente ha modificato il
record e ha salvato le proprie modifiche.
Modificare di nuovo il record.
-----------------------
Questo è un problema di Resync ovvero Jet non riesce a rileggere il record
dopo la variazione, Profiler non è di gran aiuto perchè il resync viene
fatto (ad esempio) da questo comando
---------------
exec sp_execute 72, 3
----------------
Resta il fatto che l'aggiunta del campo timestamp *evita* il messaggio di
errore.
Dico evita perchè non risolve completamente il problema infatti il resync
non viene effettuato.
es...
data questa tabella e il suo trigger
-------------------
Create Table Tab1
(Id int identity(1,1) primary Key,
Campo1 varchar(50),
Campo3 Varchar(50),
Campo4 Int,
DATAAGG DATETIME
)
GO
Create Trigger TR_Tab1
ON Tab1
FOR INSERT, UPDATE
AS
UPDATE Tab1
SET DATAAGG=GETDATE()
FROM Tab1
WHERE ID IN (SELECT ID FROM INSERTED)
----------------------
Prova ad inserire 3 righe
---------------
Id Campo1 Campo3 Campo4
1 A1 B1 1
2 A2 B2 2
3 A3 B3 3
--------------
Il campo DATAAGG viene compilato e restituito ad Access correttamente.
Chiudi la tabella, riaprila, modifica Campo1 di tutte le righe
---------
Campo1
AA1
AA2
AA3
---------
(dovresi notare che dopo la variazione il campo DATAAGG mantiene il vecchio
valore, segno che il resync non ha avuto successo)
riposizionati sulla prima riga e modifica il campo1......, ecco, appena
premi un pulsante della tastiera ti viene notificato l'errore di resync.
---------------------
I dati sono stati modificati
Prima di salvare le modifiche ai dati, un altro utente ha modificato il
record e ha salvato le proprie modifiche.
Modificare di nuovo il record.
-----------------------
adesso aggiungi il campo timestamp
------------
Alter Table Tab1
Add timestamp
------------
scollega e ricollega la tabella in access e ripeti l'operazione di
variazione.
Potrai notare che il campo DATAAGG mantiene sempre il vecchio valore ma
l'errore non viene notificato.
(Per fortuna lavoro solo con Progetti ADP di Access collegati a SqlServer
via ADO e questo problema del Resync è facilmente superabile inserendo nella
proprietà *Comando di Resync* delle maschere la stringa SQL appropriata.)
Ciao Giorgio
Jenga
Un inchino e un grazie immenso sono d'obbligo!
Jenga
giorgio rancati <giorgio_No_Sp...@tiscali.it> ha scritto:
[CUT]
>
> Ciao Giorgio
>
--
Quando un uomo con la pistola incontra un
uomo con il fucile,
quello con la pistola è un uomo morto.
Matteo Barsotti
> Grande chiarezza e grande competenza!!
> Un inchino e un grazie immenso sono d'obbligo!
>
Rinnovo la mia gratitudine.
Ciao
--
Matteo Barsotti
C.B.Sistemi
Tel. 041 976162
www.cbsistemi.it