+ Rispondi al Thread
Visualizzazione dei risultati da 1 a 7 su 7

Discussione: Salvataggio DGV su tabella Access non funziona

  1. #1
    collega non è in linea Scolaretto
    Post
    185

    Salvataggio DGV su tabella Access non funziona

    Cercando un po’ (tanto) in giro per i Forum, ho scritto questo codice per riempire una DGV con i dati di una tabella Access. Poi, dopo averli modificati sulla griglia stessa, (so che non si dovrebbe fare, ma impiegare un form di convalida sarebbe troppo macchinoso), devo salvare la griglia sulla stessa tabella.
    Mentre la routine di apertura va bene, il salvataggio no. Ho fatto tante prove, ma non sono riuscito a capire cosa devo correggere. Se cancello con Canc su una cella vuota, non succede niente. Se invece cancello una cella scritta, appare il messaggio: “Query troppo complessa”. La stessa cosa avviene se provo a scrivere in una cella vuota. E la tabella chiaramente non si aggiorna.
    La tabella ha il primo campo ID numerico, tutti gli altri sono formato Testo, di lunghezza 255 e con la possibilità di lunghezza zero.
    Lo stesso database lo uso da anni con VB6, non ha mai dato problemi.

    codice:
    Imports System.Data
    Imports System.Data.OleDb
    
    Public Class Form1
        Dim con As New OleDb.OleDbConnection
        Dim sql As String
        Dim da As OleDb.OleDbDataAdapter
        Dim dt As New DataTable
        Dim cb As OleDbCommandBuilder
        Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
    
            con.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Application.StartupPath & "\Ant2019.mdb;"
            con.ConnectionString &= "Jet OLEDB:Database Password=dodicimesi;"
            con.Open()
            sql = "SELECT * FROM TabA"
            da = New OleDb.OleDbDataAdapter(sql, con)
            da.FillSchema(dt, SchemaType.Source)
            da.Fill(dt)
            DataGridView1.DataSource = dt.DefaultView
            con.Close()
     End Sub
    
        Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
            
            con.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & Application.StartupPath & "\Ant2019.mdb;"
            con.ConnectionString &= "Jet OLEDB:Database Password=dodicimesi;"
            con.Open()
            Try
                sql = "SELECT * FROM TabA"
                da = New OleDbDataAdapter(sql, con)
                cb = New OleDbCommandBuilder(da)
                da.Update(dt)
            Catch ex As Exception
                MessageBox.Show(ex.Message)
            End Try
            con.Close()
        End Sub
    
        Private Sub DataGridView1_KeyDown(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs) Handles DataGridView1.KeyDown
            If e.KeyCode = 46 Then DataGridView1.CurrentCell.Value = ""
        End Sub
    Mi potete aiutare a risolvere?
    Grazie in anticipo

  2. #2
    Sgrubak non è in linea Scolaretto
    Luogo
    Torrazza Piemonte
    Post
    257
    Hai provato a modificare la variabile [sql] sostituendo l'asterisco con tutti i nomi dei campi?

  3. #3
    L'avatar di Brontolo
    Brontolo non è in linea Very Important Person
    Post
    2,828
    Non devi aprire e chiudere la connessione in ogni evento.
    Il regolamento del forum: la prima cosa da leggere.

  4. #4
    collega non è in linea Scolaretto
    Post
    185
    Grazie per l’interessamento. Ho provato ad aprire la connessione al Form_load e a chiuderla solamente al salvataggio, ma non cambia niente.
    Per quanto riguarda sostituire la SQL con il nome dei campi, ci proverò, anche se non è molto agevole. La tabella ha 102 campi, chiamati 1,2,3 etc fino a 102, più il primo, l’ID.
    Il numero di righe della tabella è fisso, 207. In pratica sono più di 21.000 celle, che posso scorrere con le frecce. Lo so che può sembrare illogico, e magari stupido, ma così va benissimo, (almeno con VB6 dove utilizzo una MSFlexGrid), da dieci anni.
    La tabella ha il numero di riga prefissato, cioè gli ID ci sono tutti e 207; quindi, anche se carico una tabella vuota, questa ha già scritti gli ID. Inoltre il numero di riga non parte da 1 ma da zero. Questi due fatti possono costituire il problema? Ma in VB6 funziona.
    L’unica differenza con il programma in VB6, è che carico e salvo una MSFlexGrid ciclando tutte le righe e tutte le colonne. (Durante i cicli scrivo e leggo dei tag che mi permettono di ricolorare e riformattare le celle). Avrei voluto fare la stessa cosa, ma non mi è riuscito di farlo con VB.net e la DGV, quindi volevo provare a caricare e salvare la griglia in un colpo solo, facendo poi i cicli dopo l’apertura e prima del salvataggio.
    Ma la tabella è la stessa. L’unica cosa che mi viene in mente ora, è che al salvataggio, prima di copiare la griglia nel database, con il programma in VB6, vuoto la tabella.
    codice:
    CnnDB.Execute "DELETE * From TabA"
    Devo farlo anche adesso, prima, o dopo, di:
    codice:
    sql = "SELECT * FROM TabA"
    ?
    Ma perché allora VB risponde Query troppo complessa solo se ho apportato una modifica anche ad una sola cella?
    Se avete un pò di tempo da dedicarmi... grazie in anticipo.

  5. #5
    Luogo
    Lazio
    Post
    1,597
    Blogs
    21
    mi sembra che prima dell'update manchi l'struzione:

    da.UpdateCommand = cb.GetUpdateCommand();
    Ciao sspintux
    ------------------------------------------------------------

    O Santo Protettore dell'informatico quadratico medio, se puoi allontana da me questo cetriolo amaro!
    Azz! ... questo è un grande porck-around; potremmo addirittura farlo passare per una funzionalità avanzata

  6. #6
    collega non è in linea Scolaretto
    Post
    185
    No, sspintux, neanche quell’istruzione ha smosso le acque. Il disco si è incantato su Query troppo complessa. La tabella l’avevo fatta con Access97, e non posso modificarla, né convertirla perché ha la password. Appena riesco a recuperare un programma Access97, voglio provare a rimpicciolire la tabella, sia come numero di campi che di righe. Io come programmatore sono proprio una schiappa, ma mi è venuto in mente che potrebbe essere un problema del genere.
    (Però resta il fatto che con VB6 funziona benissimo.). Se qualcuno ha qualche idea…Grazie in anticipo.

  7. #7
    Luogo
    Lazio
    Post
    1,597
    Blogs
    21
    Quote Originariamente inviato da collega Visualizza il messaggio
    No, sspintux, neanche quell’istruzione ha smosso le acque.
    Probabilmente il comando di update auto generato mette in AND tutti i campi e questo causa il problema
    visto il numero elevato di colonne.

    Se non hai problemi di concorrenza e non puoi ripensare la tabella ,
    potresti generarti tu il comando di Update
    in base alla sola PK della tabella ( o usando un solo campo tipo timestamp o GUID)

    Questo dovrebbe essere un esempio di comando di update custom

    https://docs.microsoft.com/it-it/dot...h-dataadapters
    Ciao sspintux
    ------------------------------------------------------------

    O Santo Protettore dell'informatico quadratico medio, se puoi allontana da me questo cetriolo amaro!
    Azz! ... questo è un grande porck-around; potremmo addirittura farlo passare per una funzionalità avanzata

+ Rispondi al Thread

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi