Newsgroup: it.comp.appl.access
Titolo: Un altro utente sta tentando di modificare gli stessi dati (tabella SQL tramite ODBC, solo su record nuovi...)

Ciao
ho un db con tabelle collegate tramite ODBC da SQL Server.
Si verificano alcune strane anomalie, del tipo che un'istruzione DELETE vada in errore senza essere eseguita, o che ci vada una semplice SELECT, ma solo in alcuni punti del codice.
Altra anomalia, posso inserire manualmente un record in tabella ma non posso più modificarlo o eliminarlo, ricevo il messaggio in oggetto. Un problema di chiavi primarie direte, ma invece no.
Non solo le chiavi primarie ci sono, ma posso tranquillamente modificare i record già esistenti, ma non quelli che aggiungo.
Ovviamente mi sta sfuggendo qualcosa, data l'ora, quindi se qualcuno mi fa notare cosa lo ringrazio davvero!
 
Davide

 Davide
 
Ciao,
per le "strane anomalie" bisognerebbe restringere un po' il campo: che tipo di tabella, che connessione, che errore/anomalia.
 
Riguardo l'aggiornamento dei record appena inseriti:
Dici "posso inserire manualmente" quindi la tabella è collegata e aprendola direttamente dall'interfaccia di access (o usi un form o altro?) inserisci un record, passi al successivo, torni al precedente e tentando di modificarlo la cosa fallisce?
Non è che la definizione della tabella è stata modificata in sql e non è stato aggiornato il collegamento in Access?
Esiste un campo timestamp su questa tabella?
Di che tipo è la chiave primaria?
 
Ciao
Mat.

 Di che tipo è la chiave primaria?
 
ID int IDENTITY(1,1) NOT NULL
 
Tieni conto che lavoro con tabelle collegata ad Access con database SQL dal 1998, mai vista una cosa così.
Ovviamente deve trattarsi di un problema della tabella, ma onestamente non capisco la causa.
 
Ciao

Operi esclusivamente da Form intendo bene...?
Non apporti modifiche o altro da codice su RS...?
Puoi provare a mettere un Breack su BeforeUpdate di Form e verificare la proprietà Dirty...?
 
Mi viene il dubbio che qualche cosa rimanga appeso... Ma è decisamente anomalo.
 
@Alex

Il problema dovrebbe essere il campo timestamp

 No
L'unica cosa che mi viene in mente è che, non essendoci il timestamp, Access cerchi di verificare la versione del record confrontando campo per campo e non riesca a farlo.
Magari c'è qualche campo di tipo "insolito" all'interno della tabella, non i soliti int, varchar ma binary, geography, datetimeoffset



Ciao Alex,
il problema si verifica sia direttamente operando sulla tabella, sia tramite recordset.
 
NON c'è campo timestamp, in nessuna tabella dei miei molti database SQL che uso normalmente senza problemi.
non ci sono campi di tipo strano.
 
Ecco a voi la query che ha creato la tabella:
 
CREATE TABLE [dbo].[Programmazione](
	[IDProg] [int] IDENTITY(1,1) NOT NULL,
	[IDFase] [int] NULL,
	[IDOperatore] [int] NULL,
	[DataOra] [datetime] NULL,
	[TempoImpiegato] [int] NULL,
	[Terminata] [bit] NULL,
	[CodiceCapo] [nvarchar](255) NULL,
	[Quantita] [int] NULL,
	[IDColore] [int] NULL,
	[IDTaglia] [int] NULL,
	[IDPia] [int] NULL,
	[IDLista] [int] NULL,
	[Sequenza] [int] NULL,
	[InLavorazione] [int] NULL,
	[IDGruppo] [nvarchar](255) NULL,
	[Auto] [int] NULL,
	[Scarta] [bit] NULL,
	[TempoPreparazione] [int] NULL,
 CONSTRAINT [PK_Programmazione] PRIMARY KEY CLUSTERED 
(
	[IDProg] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
 
Senza censure...
 
Non ci sono vincoli con altre tabelle o altre limitazioni.
La query NON è stata modificata dopo la creazione tramite questo codice.
La tabella è stata riempita con una query di accodamento da una tabella identica senza problemi (questi sono i record che risultano modificabili in access)
 
Tentativi eseguiti:
Compatta e ripristina
Creazione DB vuoto e reimportazione di tutti gli oggetti
Eliminazione della tabella collegata e ricollegamento
 
Accetto sempre suggerimenti
 
Ciao
Davide

 La query NON è stata modificata dopo la creazione tramite questo codice.
CUT
 
Volevo dire che la tabella non è stata modificata dopo la creazione...


Ciao
il problema sono i campi bit che rimangono Null (access "pretende" che siano True o False).
Aggiungi un Default constraint che metta a 0 il valore del campo durante la creazione.
 
Ciao
Mat.

Il giorno giovedì 16 novembre 2017 16:45:43 UTC+1, Potone ha scritto:
[CUT]
Mi permetto un consiglio spassionato: l'aggiunta di un campo timestamp alle tabelle che usi collegate in Access farebbe risparmiare alle tue applicazioni svariate interrogazioni complesse per verificare le modifiche concorrenti, che si traducono in minore larghezza di banda usata sulla rete e risorse sul server libere per altri scopi.
Nel caso specifico di questo post il timestamp avrebbe ovviato anche problema dei bit Null (seppur con Access è meglio avere i bit impostati a 0).
 
Ciao
Mat.

 ...
 
Anche per me sembra di essere la mancanza di un Timestamp che 
personalmente uso in ogni tabella che viene collegata ad Access. Basta 
già p.e. il campo
[Terminata] [bit] NULL
per poter dare problemi in rispetto ad essere paragonabile/aggiornabile.
 
Vedi il paragrafo "Supporting Concurrency Checks" nel classico articolo 
di Andy Baron:
 
https://technet.microsoft.com/en-us/library/bb188204(v=sql.90).aspx#optaccsql_topic3
 
 
-- 
Ciao
Karl
*********
http://www.AccessDevCon.com
 
Access FAQ: 
http://www.donkarl.com/it
 
 


Karl è il migliore, non ci sono dubbi.
Infatti è proprio il campo bit a dare problemi.
 
E dire che lo sapevo qualche anno fa, ma mi ero completamente dimenticato.
 
La memoria comincia a presentare qualche buco, sarà l'età...
 
Ciao
Davide


Hai perfettamente ragione.
Grazie


Sto valutando anche questa modifica, farò delle prove di prestazione.
 
Ciao