Newsgroup: it.comp.lang.visual-basic
Titolo: [?] Campi Contatore ADO

Ciao a tutti!
Sto cercando di creare un Database Access 2000
con ADO.
Tutto bene, usando ADOX è abbastanza semplice e
funziona per tabelle con campi abbastanza "standard".
Il problema è che non vedo come creare campi
contatore ad autoincremento e campi memo come
facevo con DAO....   Non è che, siccome con ADO
è possibile interfacciare DataBase di diverso tipo,
queste caratteristiche non ci sono perchè non tutti
i DB le supportano ?  (terrooore....)
Grazie ciao
Bepi

 ha scritto nel messaggio
news:9eouvf$gnb4$1...@ID-56313.news.dfncis.de...


 Access!!
Questo lo immagino... Infatti a me serve solo in fase di creazione.
Resta il dubbio dei campi memo....
Ma non esiste un tutorial dove trovare tutte queste informazioni ?
Sull'help del VB non riesco a trovare nulla.
Grazie
Bepi

 ha scritto nel messaggio
news:9ep3ab$hm2e$1...@ID-56313.news.dfncis.de...


 Access!!
Funziona, grazie.
Non va subito al momento della creazione della colonna
però.  devo creare tutta la Table, poi settare le proprietà
delle varie colonne in un secondo momento.   Appena
creata la colonna, oAdxTbl.Columns(0).Properties.Count
vale zero.   Si popola dopo. e compaiono una quindicina
di properties, fra cui autoincrement e' la prima.
Tutto ok, comunque.
Però ora mi viene un dubbio:  se cambio la stringa di
connect per utilizzare un DB differente....  potrebbe non
funzionare ?   C'è un modo sicuro per interfacciare un
qualsiasi database ?   Alla base di tutto il discorso con
il cliente c'è il fatto che attualmente useremo mdb per
iniziare, poi si dovrà migrare ad un DB più potente,
senza dover riprendere in mano il codice.
E' una utopia ?
Grazie ancora
Bepi

 E' una utopia ?
Appunto:
non usare campi autoincrement: hanno senso solo in ottica di semplificazione
delle prodedure di indicizzazione.
Usa una tua chiave primaria che gestisci da codice, o da stored proc al più
(su database più performanti di access).
ciao
ugo


Ti ringrazio per il consiglio, che seguiro' volentieri
poiche' il sw e' ancora a livello di analisi, quindi
sono ancora in tempo a fare tutte le modifiche che
voglio.
Ma alla fine, esiste un modo per sapere quali sono
le funzionalità che e' meglio evitare se si vuole che
il sw sia il piu' compatibile possibile ?
A intuito posso pensare che vadano evitati i campi
memo, e posso anche immaginare che vada posta
anche particolare attenzione nelle query, onde
evitare di utilizzare espressioni che appartengano
solo ad un particolare dialetto....  ma capisci che
non posso certo stressare il NG con valanghe di
domande ogni giorno...
Possibile che non esista un tutorial, help, o una
cosa qualsiasi che metta a confronto i vari DB e
che spieghi esattamente cosa si puo' fare e cosa
si deve evitare per mantenere la compatibilita fra
DB ?
Grazie
Bepi


Questo non lo so, ma valgono le regole già enunciate da te stesso.
Tieni presente che anche stando su Database rispondenti alle specifiche ANSI
92 (Vedi Sql Server e Oracle, tanto per capirci) esistono belle differenze
nell'uso 
p.es
 delle funzioni di computo di datetime o di cast.
Se poi vuoi prendere in considerazione database che magari introducono
"estensioni" (sul cui significato molto si dibatte) proprietarie, l'affare
si complica.
E questo solo sul piano delle rispondenze alle specifiche SQL.
Se prendi in considerazione i tipi di dati e di campi, ti accorgerai, 
p.es
.
che esistono differenze filosofiche non da poco, ad esempio fra l'approccio
"tutto nel database", tipico di Oracle, e quello "i dati nel database, i
file nel file-system" tipico di SqlServer.
E così via...
In definitiva il consiglio migliore è: cerca di prendere una direzione a
livello di analisi progettuale, considera sul piano:
a) Prestazionale
b) Economico (anche qui le differenze sono notevoli)
c) "filosofico"
i vari candidati a database per la tua app.
e cerca di seguire la strada che ritieni vincente.
ciao
ugo