[Forse OT] - Consenti lunghezza zero: valore "sbagliato"

[Alexx]

Ciao!

Scusate, ho un problema che non mi spiego.
Ho un database Access che era in versione 97 (forse prima anche in versione
95), ma e' stato convertito in versione 2000.
Se visualizzo la struttura delle tabelle attraverso l'interfaccia di Access,
su alcune colonne di testo trovo la proprieta' "Consenti lunghezza zero"
impostata a "Si'". Se, pero', verifico la stessa proprieta'
(AllowZeroLength) usando DAO, ADO, ADOX... la trovo impostata a "false". Se
faccio la stessa prova su un database nuovo, tutto e' perfettamente
coerente.

Qualcuno sa dirmi perche' trovo due valori diversi e come posso risolvere il
problema?
Sbaglia l'interfaccia grafica di Access o sbagliano DAO, ADO...
Se il problema e' sul database, qualcuno sa dirmi come correggerlo?

Se, attraverso una query di aggiornamento, provo a mettere una stringa vuota
nel campo incriminato, non ottengo alcun errore.
Se, invece, attraverso la visualizzazione della struttura, imposto la
proprieta' "Consenti lunghezza zero" a "No", eseguendo la precedente query
di aggiornamento ottengo un errore.

Grazie a tutti.

Alex

P.S. Ho postato lo stesso quesito su microsoft.public.it.office.access.

[Nicola Ottomano]

Alexx ha scritto:

> Qualcuno sa dirmi perche' trovo due valori diversi e come posso risolvere il
> problema?

Guarda, è da molto che non lavoro con Access.
Ero incappato pure io in un errore del genere.
Se non ricordo male i valori "Consenti Lunghezza Zero" e
"AllowZeroLength" si riferiscono a due priprietà differenti.
Una è la stringa di zero caratteri, l'altra a valori NULL
Però prendila con le pinze... ormai sono 4 anni che Access ha lasciato
il mio pc.

Nicola

[Alexx]

Grazie per la risposta.

> Guarda, è da molto che non lavoro con Access.
> Ero incappato pure io in un errore del genere.
> Se non ricordo male i valori "Consenti Lunghezza Zero" e
> "AllowZeroLength" si riferiscono a due priprietà differenti.
> Una è la stringa di zero caratteri, l'altra a valori NULL

In effetti, cosi' sembrerebbe, dal momento che possono avere valori diversi.
Tuttavia, io non trovo un'altra proprieta' corrispondente. A me pare che sia
proprio la stessa proprieta'. Quella che si riferisce ai valori null mi pare
sia "Nullable" (o qualcosa del genere) e direi che e' il negativo della
proprieta' "Richiesto".
Come scrivevo, se effettuo la verifica su un database nuovo, tutto e'
perfettamente coerente (Consenti lunghezza zero => Si'; AllowZeroLength =>
True).
Altro particolare: reimpostando il valore della proprieta' da Access, tutto
sembra tornare ad allinearsi. Purtroppo non posso scorrere e reimpostare
manualmente tutti i campi di testo del database. Oltretutto, non saprei come
testare i campi di testo, dal momento che c'e' questa discordanza: io leggo
sempre la proprieta' "sbagliata".

> Però prendila con le pinze... ormai sono 4 anni che Access ha lasciato
> il mio pc.

Anche io vorrei... :-) Il problema e' venuto fuori proprio in seguito al
proposito di abbandonare Access: abbiamo testato un tool di migrazione da
Access a SQL Server che pare molto bello... ma pare leggere (e impostare su
SQL) gli stessi vincoli "errati" su alcuni campi di testo.
Per far migrare centinaia di clienti da Access a SQL Server, devo essere
proprio sicuro...

Mi e' capitato di leggiucchiare che da Access 97 a 2000 e' cambiato qualcosa
nella gestione di quella proprieta': in pratica, prima il valore predefinito
era True, dopo era false. Alcuni campi, negli anni, sono stati aggiunti al
database, quindi potrebbero essere stati aggiunti con attributi diversi. Ma
in tutto cio' non vedo un motivo per trovare due valori diversi sulla stessa
proprieta'...

Grazie ancora.

Alex

[Nicola Ottomano]

Alexx ha scritto:

Non molto tempo fa ho utilizzato un software chiamato DTM Migration Kit
http://www.sqledit.com/mk/
Costa sui 120 Euro (in dollari l'avevo pagato 150 $ circa) e consente la
migrazione dei dati da qualsiasi db verso qualsiasi altro db, passando
per connessioni ODBC.
Oggi, lavorando in un'azienda che si occupa anche di ETL, non lo sto
utilizzando più, avendo sviluppato alcune routine aziendali che utilizzo
a questi scopi.

Guarda sul loro sito se ti interessa ed, eventualmente, ti vendo la mia
licenza originale con l'aggiornamento all'ultima versione.

Un ultimo consiglio: se l'applicazione non è fortemente multi utente
(quindi diciamo da 1 a 5 utenti contemporanei) il consiglio è di passare
a soluzioni leggere, veloci ed open come SQLite (di cui ci sono i
provider ADO e ADO.NET a disposizione).

Nicola

[Alexx]

> Non molto tempo fa ho utilizzato un software chiamato DTM Migration Kit

> [...]

Noi finora abbiamo provato diversi tool di vari produttori, fra i quali SQL
Server Migration Assistant for Access, di Microsoft.

> e consente la
> migrazione dei dati da qualsiasi db verso qualsiasi altro db, passando
> per connessioni ODBC.

Connessioni ODBC...? Significa dover impostare obbligatoriamente delle
connessioni ODBC per ogni archivio da migrare?
Comunque, daremo un'occhiata.

> Un ultimo consiglio: se l'applicazione non è fortemente multi utente
> (quindi diciamo da 1 a 5 utenti contemporanei) il consiglio è di passare
> a soluzioni leggere, veloci ed open come SQLite (di cui ci sono i
> provider ADO e ADO.NET a disposizione).

Grazie per il consiglio, ma abbiamo motivi per andare decisamente verso SQL
Server.

Alex

[Alexx]

>> Non molto tempo fa ho utilizzato un software chiamato DTM Migration Kit
>> [...]

Io e un collega gli abbiamo dato un'occhiata, ma ci pare piu' grezzo dei
tools che abbiamo provato fino ad ora.
Comunque grazie.
Nel frattempo, grazie ad un suggerimento ricevuto su
microsoft.public.it.office.access, ho verificato che il problema si risolve
se importo tutte le tabelle su un altro database nuovo. Purtroppo si
verifica un altro problema, ma forse piu' risolvibile.

Alex

[Wodka40[Google]]

On 12 Mar, 14:15, "Alexx" <alex_rav...@hotmail.com> wrote:
> Ciao!
>
zac
ho letto i vari passaggi!
Reputo che il problema sia nella conversione 95->97->2000
...probabilmente la struttura è davvero cambiata attraverso le varie
versioni!
La conferma sarebbe che impostando il nuovo dato da access "attuale"
tutto va a posto!
Però potrebbe essere anche un problema di versione provider ADO o
nersione di DAO

Probabilmente usando vecchie versioni di DAO/ADO il provider
interpreta la struttura delle tabelle di sistema correttamente e non
ti "esprime" il suo sdegno nei confronti di questo (provbabilmente)
obsoleto valore!

Può darsi che tu usi un ADO/DAO "recente" che non interpreta
correttamente una struttura obsoleta....e quindi reimpostandola "a
mano" sostituisci la versione vecchia non riconosciuta con quella
nuova!

Io propenderei per l'ipotesi DAO/ADO incompatibile con la versione del
tuo DB!

Perchè l'alternativa sarebbe tremenda: una struttura tabelle che non
fà quello che desideri e quindi potenzialmente fonte di infiniti bugs!

Visto che mi parli di centinaia di installazioni
...non penso che un pomeriggio speso a rifare exnovo una struttura
tabelle e relative query di import sia denaro
buttato!....anzi!...meglio che distribuire versioni di dao ado vecchie
ai vari clienti!

e siccome non sono polemico....
tralascio quello che penso sul fidarsi delle varie conversioni
automatiche e sul relativo debugging!
;o)