View Full Version : [VB6] Problema textbox su 2 pc!
:help: Buonasera,
ho creato un programma e in un determitato form inserisco un valore in euro cioè sarebbe il prezzo...è una textbox questo valore viene salvato in un database access. se lo provo sul pc dove ciò installato visual basic se inserisco un valore come 250 o 250.50 o 250,50 non ho problemi nel primo mi inserisce 250 nei secondi 250.50. Mentre ho provato a installarlo su un'altro pc e se inserisco 250 va bene se inserisco 250.50 nel database salva 25050 mentre se inserisco 250,50 mi da errore sull'istruzione sql come mai?i due programmi sono identici. grazie :help:
:help: Buonasera,
ho creato un programma e in un determitato form inserisco un valore in euro cioè sarebbe il prezzo...è una textbox questo valore viene salvato in un database access. se lo provo sul pc dove ciò installato visual basic se inserisco un valore come 250 o 250.50 o 250,50 non ho problemi nel primo mi inserisce 250 nei secondi 250.50. Mentre ho provato a installarlo su un'altro pc e se inserisco 250 va bene se inserisco 250.50 nel database salva 25050 mentre se inserisco 250,50 mi da errore sull'istruzione sql come mai?i due programmi sono identici. grazie :help:
I due programmi sono identici, ma potrebbero non esserlo le versioni di Access che hai sulle 2 macchine.
Access, a seconda della versione ( intendo anche la versione di ADO ), può accettare un dato passato non proprio correttamente, interpretandolo nel modo giusto, oppure rifiutarlo.
Devi anzitutto controllare in Access se quel campo è impostato correttamente per accettare un numerico con virgola.
I due programmi sono identici, ma potrebbero non esserlo le versioni di Access che hai sulle 2 macchine.
Access, a seconda della versione ( intendo anche la versione di ADO ), può accettare un dato passato non proprio correttamente, interpretandolo nel modo giusto, oppure rifiutarlo.
Devi anzitutto controllare in Access se quel campo è impostato correttamente per accettare un numerico con virgola.
Avevo pensato a questo problema infatti dove ciò installato visual basic ho office 2003 mentre dove ho provato sull'altro pc ho office 2007, infatti per togliermi ogni dubbio ho provato su un'altro pc che ha office2003 ma niente ho sempre il problema.cmq il campo è un numerico con precisione doppia
Avevo pensato a questo problema infatti dove ciò installato visual basic ho office 2003 mentre dove ho provato sull'altro pc ho office 2007, infatti per togliermi ogni dubbio ho provato su un'altro pc che ha office2003 ma niente ho sempre il problema.cmq il campo è un numerico con precisione doppia
Se il campo è numerico con precisone doppia allora devi fare in modo di evitare che l'utente possa scrivere "250,50".
VB6 passa i decimali con il punto.
250.50 non dovrebbe creare mai problemi.
Se inoltre nella INSERT fai riferimento diretto alla TextBox ( cosa che sarebbe sempre meglio evitare ) puoi risolvere, da così :
strINSERT = "INSERT INTO nomeTabella (camponumero) " & _
"VALUES (" & Text1.Text & ")"
a così :
strINSERT = "INSERT INTO nomeTabella (camponumero) " & _
"VALUES (" & Replace(Text1.Text, ",", ".") & ")"
Se il campo è numerico con precisone doppia allora devi fare in modo di evitare che l'utente possa scrivere "250,50".
VB6 passa i decimali con il punto.
250.50 non dovrebbe creare mai problemi.
Se inoltre nella INSERT fai riferimento diretto alla TextBox ( cosa che sarebbe sempre meglio evitare ) puoi risolvere, da così :
strINSERT = "INSERT INTO nomeTabella (camponumero) " & _
"VALUES (" & Text1.Text & ")"
a così :
strINSERT = "INSERT INTO nomeTabella (camponumero) " & _
"VALUES (" & Replace(Text1.Text, ",", ".") & ")"
Antonio sono d'accordo con te però io ho il problema che se l'importo lo scrivo con il punto per esempio 250.56 non mi considera proprio il punto cioè mi considera 25056 cosa che sul pc dove ho visual basic mi prende 250.56. E' questa la cosa strana infatti io alla textbox gli proibisco tutto tramite questa funzione:
Private Sub importo_KeyPress(KeyAscii As Integer)
'Controllo per non far inserire caratteri errati
Select Case KeyAscii
Case Is < 32
Case 44 To 46
Case 48 To 57
Case Else
KeyAscii = 0
End Select
End Sub
per escludere la virgola basta che al posto di 44 metto 45 però ho il problema che su altri pc il punto non lo considera e se metto la virgola lo prende come carattere errato.
Cmq cerco di fare altre prove e ti faccio sapere
banryu79
21-11-2008, 17:12
Ok la sparo: non potrebbe avere a che fare con le impostazioni di formato per le cifre in Access?
In passato ho avuto un problema analogo, in un'applicazione java momentaneamente appoggiata su Access come db (per rapida prototipazione) con risultati diversi nell'inserimento di valori via SQL nei campi a doppia precisione se le impostazioni locali consideravano il punto '.' come separatore dei decimali piuttosto che separatore delle migliaia (e la virgola di conseguenza).
Non ricordo se e come abbiamo risolto, dato che una volta impostate le tabelle abbiamo migrato tutto su HSQL, il db target.
P.S.: Java dialogava con Access via JDBC, quindi la faccenda potrebbe essere diversa, non sono un esperto in materia.
Antonio sono d'accordo con te però io ho il problema che se l'importo lo scrivo con il punto per esempio 250.56 non mi considera proprio il punto cioè mi considera 25056 cosa che sul pc dove ho visual basic mi prende 250.56. E' questa la cosa strana infatti io alla textbox gli proibisco tutto tramite questa funzione:
Private Sub importo_KeyPress(KeyAscii As Integer)
'Controllo per non far inserire caratteri errati
Select Case KeyAscii
Case Is < 32
Case 44 To 46
Case 48 To 57
Case Else
KeyAscii = 0
End Select
End Sub
per escludere la virgola basta che al posto di 44 metto 45 però ho il problema che su altri pc il punto non lo considera e se metto la virgola lo prende come carattere errato.
Cmq cerco di fare altre prove e ti faccio sapere
"Antonio" ? :D
1. Problema della virgola : è forse dovuto al fatto che quando concateni la stringa Insert, quella virgola può essere interpretata come separatore dei valori ( l'errore dice che il numero dei campi non corrisponde col numero dei valori passati nella Insert... ). La soluzione è semplice. Basta trattare il numero decimale come stringa :
Dim val As Double
val = CDbl(Text1.Text)
Dim strINSERT As String
strINSERT = "INSERT INTO nomeTabella (numero) " & _
"VALUES (" & "'" & val & "'" & ")"
Access capirà... ;)
2. Problema del separtore decimale : credo abbia ragione banryu, forse non è un'impostazione di Access, bensì proprio l'impostazione locale di sistema sul separatore dei decimali.
Da VB6 puoi conoscere via codice l'impostazione locale, ad esempio, con queste chiamate ( da mettere in un modulo - la Function da usare è GetDecimalSep ) .
Public Declare Function GetLocaleInfo Lib "KERNEL32" _
Alias "GetLocaleInfoA" _
(ByVal Locale As Long, _
ByVal LCType As Long, _
ByVal lpLCData As String, _
ByVal cchData As Long) As Long
Public Const LOCALE_SDECIMAL = &HE
Public Declare Function GetThreadLocale Lib "KERNEL32" () As Long
Public Declare Function GetSystemDefaultLCID Lib "KERNEL32" () As Long
Public Declare Function GetUserDefaultLCID Lib "KERNEL32" () As Long
Public Function GetDecimalSep() As String
Dim LCID As Integer
Dim Data As String
Dim Ret As Integer
Dim DataLen As Long
LCID = GetThreadLocale
Ret = GetLocaleInfo(LCID, LOCALE_SDECIMAL, Data, DataLen)
If Ret <> 0 Then
DataLen = Ret
Data = Space(DataLen)
Ret = GetLocaleInfo(LCID, LOCALE_SDECIMAL, Data, DataLen)
End If
GetDecimalSep = Left(Data, DataLen - 1)
End Function
In questo modo dovresti intercettare ogni eccezione, e riuscire ad inserire su tutti i sistemi in ogni caso ( chiaro che se su un sistema l'utente avesse fantasiosamente definito "@" come separatore decimale, dovrai gestire anche quello... ).
Perciò soluzione 1. + soluzione 2. :
Dim val As Double
Dim separatoreDec As String
separatoreDec = GetDecimalSep
If separatoreDec = "," Then
val = CDbl(Replace(Text1.Text, ".", ","))
End If
If separatoreDec = "." Then
val = CDbl(Replace(Text1.Text, ",", "."))
End If
Dim strINSERT As String
strINSERT = "INSERT INTO nomeTabella (numero) " & _
"VALUES (" & "'" & val & "'" & ")"
Prova...
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.