Newsgroup: it.comp.appl.access
Titolo: Non ci posso credere!!!!!!!



Ho fatto un'applicazione con access97,  accedo al DataBase  dati(Sql-server
7.0) sito su un server NT con il driver ODBC.

Nell' esecuzione di  una query di aggiornamento oppure  di
cancellazione,

mi  risponde che non può eseguire l'operazione in quanto
non esiste una chiave univoca,

(Se a me non serve avere una chiave?????????)


questa storia mi puzza di strano,

dove posso aver sbagliato?.

Anche perchè, da SQL 7.0  la delete io riesco a farla idem
su Access.

Grazie.

 

 

 

 


Nell' esecuzione di  una query di aggiornamento oppure  di cancellazione,
mi  risponde che non puň eseguire l'operazione in quanto non esiste una
chiave univoca,
(Se a me non serve avere una chiave?????????)
------------------
Se a te non serve, a SQL serve, o meglio, al driver ODBC.
A parte il fatto che č buona norma, sempre, inserire una chiave univoca, in
qualunque tabella.
Cmq, per poter identificare in maniera univoca il record da eliminare o
modificare, ODBC ha bisogno di un riferimento... univoco, appunto.

 A parte il fatto che è buona norma, sempre, inserire una chiave univoca, in


Ti ringrazio per avermi risposto cmq tutto questo non mi convince.
Non e' questione di convincerti o no, e' proprio che ODBC ti apre un
collegamento in sola lettura se non trova una chiave primaria.
Con un po' di ricerca trovi qualcosa anche sull'help di Access. 
Nel caso di una tabella collegata tramite ODBC, l'help cita la
possibilita' di generare un indice "locale" (di cui il server non
avrebbe nessuna notizia) e che darebbe la possibilita' di accedere in
scrittura alla tabella sul server.
Ciao,
Giovanni
---
Inferno e paradiso mi sembrano sproporzionati. Le azioni degli 
uomini non meritano tanto - JLBorges

Ho capito, ma se io nelle tabelle non ho campi univoci?
Mi pare proprio una Stronz....
Sai dirmi se esistono altri tipi di driver per collegare Access 97 con
SQL 7.0 ????
Ciao,  grazie per la risposta.
Giovanni Albertone ha scritto:


Mi pare proprio una Stronz....
E' possibile che non trovi nessuna combinazione univoca di campi?
L'indice non deve necessariamente essere su un campo singolo.


 SQL 7.0 ????
Non è per essere polemico, ma una "Stronz..." è quella di non inserire campi
univoci.
Io non vedo il senso di una tabella che non contienga chiave.
Se non hai campi univoci, mettili. Fatto un campo contatore ed ecco che ha
il tuo campo univoco.

 
Giovanni Albertone a  seguire
-- Non è per essere polemico, ma una "Stronz..." è quella di non
inserire campi
-- univoci.
-- Io non vedo il senso di una tabella che non contienga chiave.
-- Se non hai campi univoci, mettili. Fatto un campo contatore ed ecco
che ha
-- il tuo campo univoco.
Andrea Sciamanna a seguire
-- E' possibile che non trovi nessuna combinazione univoca di campi?
--L'indice non deve necessariamente essere su un campo singolo.
Che bello una discussione "filosofica":
Ma per quale motivo devo avere o definire per forza una chiave????
E se a me mi tira di non farlo (a parte i tempi di risposta)
io sto con Tore Marche
Tore hai "filosoficamente" ragione secondo me c'e' qualche errore da
qualche altra parte 
Postmetto che non sono un profondo conoscitore di ODBC 
ciao a tutti
:<)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
a.cara

 E se a me mi tira di non farlo (a parte i tempi di risposta)
...ma non si può filosofeggiare senza prima conoscere un po' della storia
che ha portato alla definizione dei RDBMS.
E allora te la ripropongo.
Un bel dì un tale CODD definì attraverso semplici regole come dovrebbe
essere un database per potersi definire "relazionale".
Ti evito le altre 11 che facilmente puoi reperire con un ricerca ma ti qui
incollo quella topica:
2: ACCESSO GARANTITO: Ciascun valore deve essere raggiunto univocamente da
un nome di tabella, chiave primaria e nome di colonna; (CHIAVI PRIMARIE)
Non entro nel merito se ciò sia giusto (e lo è) o no, mi limito a
evidenziare che se un motore database vuole essere definito relazionale deve
supportare le "chiavi primarie", anzi deve, solo attraverso di esse,
permettere aggiornamenti e cancellazioni.
E questo vale per SQL Server così come per Oracle, Informix e così via.
Ciao
Ale





Intanto,  Buona giornata a tutti.

X Ale
, tu potresti aver ragione,

ma se io devo trattare dei dati in un modo sequenziale che bisogno
ho di crearmi un indice?

Comunque, il problema non è avere o non avere una Chiave primaria,

perchè tutti i DataBase che tu hai nominato riescono a gestire
operazioni di I/O anche senza indici,

Il problema nasce quando ci si deve collegare con il driver ODBC, al
quel punto vengono richiesti gli indici.

Quindi ricapitolando, se io devo gestire una tabella in modo sequenziale,
per fare le tre cazzatine :


Primo     - la devo valorizzare,


Secondo - la devo leggere,


Terzo     - la devo cancellare,


non capisco per qual motivo devo avere una chiave.

E POSSIBILE CHE NON ESISTE UN ALTRO DRIVER PER COLLEGARE ACCESS 97 E
SQL 7.0

 

CIAO TORE.

 

 




"Ale@Work" ha scritto:



X Ale, tu potresti aver ragione,
ma se io devo trattare dei dati in un modo sequenziale che bisogno ho di
crearmi un indice?
-------------
Allora usa Excel.
Comunque, il problema non è avere o non avere una Chiave primaria,
perchè tutti i DataBase che tu hai nominato riescono a gestire operazioni di
I/O anche senza indici,
Il problema nasce quando ci si deve collegare con il driver ODBC, al quel
punto vengono richiesti gli indici.
-------------
No, l'indice c'è sempre. E' che non lo vedi.
E POSSIBILE CHE NON ESISTE UN ALTRO DRIVER PER COLLEGARE ACCESS 97 E SQL 7.0
------------------
Perchè dovrebbe esistere? Va tanto bene quello che c'è. Cmq, anche se lo
trovassi, avresti lo stesso risultato.

 trovassi, avresti lo stesso risultato.
Prova con ADO, altrimenti potresti cambiare architettura, passare cioè ad un
architettura su tre livelli, con un componente server che interagisce con il db
su istanze dei FE (questo potrebbe essere un buon argomento su cui
filosofeggiare....)

E questo vale per SQL Server cosě come per Oracle, Informix e cosě via.
e poi....... se ti fai un bel cursore o recordset anche con 1865,7 :<)  righe
uguali e lo aggiorni con una bella update o il set current of  "di cursore"  non
mi sembra che access non te lo faccia fare.
ciao <:)))))) e speriamo che glenrunciter :<()))))  non si rincavoli e mi
rimandi a quel ....comp.database.*
--
Alessandro Cara

 Alessandro Cara
Paolo A.


Certo che Access te lo fa fare, ma con inutili complicanze; la logica vuole
però che si scelga il pacchetto software consono sia al progetto che alla
metodologia di programmazione scelta.
Se tu vuoi lavorare senza il vincolo progettuale che rappresentano le chiavi
primarie, e sei d'accordo a rinunciare ai conseguenti vantaggi, perché non
adoperi un pacchetto come FoxBase; in FoxBase non vengono dichiarate a
priori le relazioni tra tabelle (pertanto non servono le chiavi primarie) e
se ti serve metterle in relazione fra loro devi farlo ogni volta scrivendo
tanto codice ed otterrai risultati accettabili solo se sei un programmatore
in gamba (pensa che bello però, se sei bravino puoi anche gestirti
direttamente una relazione molti-a-molti tra due tabelle :-)))) ). Una
precisazione per chi non ha mai lavorato con DB non relazionali: il tempo di
sviluppo aumenta di 5/10 volte.
Ormai è scontato che lo standard dei DB e quello relazionale; immagino che
certi prodotti come FoxBase esistano ormai solamente per compatibilità con i
progenitori dei moderni database e per chi ha memoria si chiamavano DBI,
DBII, DBIII, DBIIIPlus, DBIV ecc.
Roberto

 mi sembra che access non te lo faccia fare.
Non ho capito niente.


qui mi scuso perche' ho citato solo access,  la gestione del cursore era riferita a
oracle e/o db2. e per quanto riguarda gli standard da che mondo e' mondo lo standard lo
ha fatto sempre il piu' FORTE
ciao
--
Alessandro Cara

 Non ho capito niente.
mi spiace di non essere stato chiaro.
E' che, il cursore ( e' un po' OT),  a cui faccio riferimento nella frase, mi
sono dimenticato di scrivere che riferiva ad ambienti non Microsoft
--
Alessandro Cara

 filosofeggiare....)
gajardo!!! A scuola dalla "Oracle" ???  mi hanno fatto piegare in due dalle risate
(come dicono i puristi?? ROTFL?)  con la storia dei tre livelli!!!!
Riassumo:
1) una volta c'era l'host (mo' e' diventato un sistema "legacy" boh?!?) con tanti
bei terminali
2) poi si sono inventati il client-server (al massimo ho visto applicazioni
file-server)
3) poi e' arrivato internet che funziona logicamente come un sottosistema IBM
chiamato CICS (fatto sta che lo chiamo un CICS con le figurine fatto male)
4) Adesso siamo arrivati ai tre livelli cioe' a) sistema centrale b) un terminale
c) un "sarchiapone" intermedio il famoso "middleware" che non si sa bene cosa
dovrebbe fare. AUGURI!!!!!!
5) a quando la bicicletta con gli sportelli????
:<)))))))))))))))))
--
Alessandro Cara

 Alessandro Cara
mi spiace contraddirti ma molti degli standard, a livello di server ad esempio non sono di
Microsoft, sono fresco fresco di un'esperienza con una procedura proxy basata su standard
internazionale che su un server NT mi ha fatto lavorare più del dovuto.
MS è si forte ma solo nei pc, e in ogni caso è forte in quanto azienda onnivora e
megamiliardaria, ma non i sembra che i suoi prodotti possano venire considerati i "best in
class", ha forse avuto il merito di semplificare e rendere maggiormente diffondibili certi
applicativi (in tal proposito ho altre belle considerazioni scritte in sanscrito....), MS
sfrutta la sua posizione dominante cercando di imporre gli standard, ma gli standard si
trovano perchè ci si mette d'accordo non perchè si impongono.
In ogni caso.... SQL l'ha inventato IBM.... l'affidabilià dei sistemi operativi di microsoft
la conosciamo....(hai mai visto AS400 in fatto di stabilità?)  nei database sono arrivati 10
anni dopo (Informix,Oracle DB2..)... e poi  devo continuare? il tutto, ti assicuro senza il
minimo spirito polemico, ma con la più alta attitudine al confronto di idee, esperienze e
convinzioni.
Paolo Aulisio

 > >[cut]

l'archittetura a tre livelli di cui parlo io non è hw ma sw (se vuoi un giorno te la
spiego). E dopo averla sperimentata personalmente, posso dirti che ne vale la pena.
Infatti con un DB con circa 240-250 tabelle, svariate con qualche decina di migliaia
di record, 20 utenti in lan, un numero n in wan, potenzialmente aperto a internet,
dove andavo con access? a pescare forse... con la tua bicicletta con gli sportelli.
Penso che nel confronto dialettico sulle conoscenze e sulle esperienze, con filosofia
community, non ci debba essere posto per lo sberleffo e la presa in giro, soprattutto
se non si capisce di cosa si stà parlando......

Sul fatto che il tuo problema con ODBC si possa risolvere SOLO aggiungendo la fatidica chiave
primaria non ci sono dubbi o incertezze.
Hai ragione tuttavia quando asserisci che non sempre le chiavi primarie servono (questo in rapporto
a jet).
Sono assolutamente necessarie per normalizzare le tabelle e creare le integrità referenziali
(fondamentali come già spiegato in altri post. non solo per un discorso di tipo prestazionale).
Ma nell'ultima tabella di una catena di relazioni è sufficiente la chiave esterna a duplicati
ammessi; l'aggiunta di una chiave primaria in questo caso non produce miglioramenti prestazionali
nelle selezioni dei records, ne è necessaria dal punto di vista "logico" visto che oltre non si può
proseguire con la normalizzazione.
Questo con jet.
Ma il punto è un altro: anche con SQL non è obbligatorio che una tabella abbia chiave primaria o
indici univoci, ma con ODBC se vuoi aggiornare tale tabella, la chiave deve esistere.
Tu imputi questo "problema" all'architettura ODBC e non al modello relazionale in generale ....
beh, hai ragione.
La dimostrazione palese è data dal fatto che una vista SQL aggiornabile (basata su tabelle con
chiave primaria) non è aggiornabile una volta collegata al tuo front-end Access.
Per renderla aggiornabile è necessario creare uno "pseudo indice" locale (senza che nulla venga
creato sul server).
Per dare una motivazione "matematica" a questa caratteristica di ODBC bisognerebbe conoscere in
profondità tale architettura..
E' un peccato che questa discussione abbia preso una piega polemica, potenzialmente è molto molto
interessante.
CIAO, warp
Alessandro Cara ha scritto nel messaggio <


 sono dimenticato di scrivere che riferiva ad ambienti non Microsoft
So cos'è un cursore... almeno quello di SQL. E i cursori, dopotutto,
esistono anche in Access... o, meglio, solo che si chiamano oggetti
recordset... e sono modificabili :-)



Ciao Warp, intanto grazie per la risposta,

Curiosità,  Ma tu sei Siciliano? lavori per caso a Italtel
? Conosco uno con il tuo stesso nome.

Ragazzi, state buoni ho creato la famigerata chiave primaria,

ho dovuto inserire un campo 
(attributo)
 contatore nelle tabelle,

in quanto le mie tabelle possono contenere records 
( tuple)

doppie,

Quindi non voglio continuare a polemizzare,  ma il creatore di
sto benedetto DRIVER e proprio un testa di ........

Li mortacci sua..............

Ciao a tutti ragazzi,

Complimenti a tutti, ottima questa NG.

 

 

 

warp ha scritto:




Non sono io, in effetti non credo essermi scelto un nick particolarmente originale :-D
CIAO, warp

 [cut]
ciao warp
credo che un pizzico di "polemica" alcune volte possa servire a patto che si mantenga nei limiti della
buona educazione e del costruttivo. Purtroppo qualche volta succede che possa esserci qualche
"fraintendimento" ma se si ha voglia di comunicare credo che queste situazioni possano essere superate.
Qualche volta succede che soprattutto "nuovi" (come me per esempio) non conoscano o non sono conosciuti
dal lato diciamo "professionale?" e quindi, ripeto, il "misunderstanding", come direbbero  gli inglesi,
puo' succedere.
Personalmente ho sempre cercato di capire chi fosse il mio interlocutore, alcune firme comincio a
conoscerle, anche per via del sito comune, ciononostante qualche "errore" lo commetto (e forse qualcuno
fa altrettanto verso me o altri). Comunque ogni tanto una discussione fa bene
--
Alessandro Cara


Credo di aver letto da qualche parte.. " E' il conflitto che scatena moti di crescita nelle
coscienze...."
A parte casuali ed evitabili incompresioni dialettiche io penso che la discussione possa continuare nel
sereno spirito del confronto e della crescita collettiva. Per parte mia, non ho la presunzione di
'essere arrivato', di 'avere la verità in tasca', anzi sono sempre pronto a mettere in discussione le
mie convizioni, ovviamente se esistono argomentazioni valide per farmi cambiare...
Saluti
Paolo

warp ha scritto:
