[C#] Interazione fra C# e database SQL Server!

[J0k3r91]

Ciao a tutti!

Mi trovo di fronte a un problema che cerco di risolvere ormai da diversi giorni.
Premetto che sono ancora uno studente e le mie conoscenze di programmazione (sopratutto se di mezzo c'è del SQL) non sono ancora proprio delle migliori!

Sto sviluppando un'applicativo C# in WPF che mi memorizzi e carichi dei dati da un database SQL Server da e nel mio programma.

Ho generato le Query GetData() e Fill() e la prima di esse funziona perfettamente.

Il mio problema sta nel Fill(): la Query SQL che mi fal'INSERT dei dati nel database è esatta (se infatti provo tramite Query Builder --> Execute Query funziona tutto e mi riempie la mia Table tblFilm senza problemi con una nuova row).

Ma come faccio a farlo tramite codice C#??

Sarà che faccio un gran casino fra sti TableAdapter, DataSet, DataTable, DataRow, ecc..!!

Al momento il mio codice in C# gira e non da errore, ma non fa proprio un bel niente!!

Qualcuno ha anche solo un codice generico per fare la Fill in un db?

La parte C# che non va è la seguente:

tblFilmTableAdapter adapt = new tblFilmTableAdapter();
DsDataFilm.tblFilmDataTable table = new DsDataFilm.tblFilmDataTable(); //il mio DataSet
DataRow row = table.NewtblFilmRow();
row["TITOLO"] = "Prova";
row["ANNO"] = 1988;
row["GENERE"] = "Action";
row["RATING"] = 5;
row["TRAMA"] = "asdfghjklpoi";
row["LOCANDINA"] = "url:\\locandina.jpg";
adapt.FillBase(table, 4); //Fill della table fatta prima nella row con ID = 4.. (@Param1)

Dove "4" sarebbe l'ID della row da riempire..





Ho in realtà due metodi Fill (Fill e FillBase) uno che accetta una table e l'altro che accetta ogni singolo parametro. Nessuno dei due tramite C# va..

In definitiva.. come faccio a creare una nuova row e a metterci tutti i miei dati??

Qualcuno sa darmi una dritta? ho cercato in giro ma non ho trovato niente che mi funzionasse!

[MarcoGG]

Non prenderla come una "critica", ma francamente non vedo il perchè di tanta complicazione per fare una Insert su una tabella sola.
Il fatto che i DataSet siano il cuore di ADO.NET non significa che sia sempre obbligatorio farne uso.
Provato con un semplicissimo SqlCommand ?
http://www.codeproject.com/KB/databa...in_csharp.aspx

[J0k3r91]

Ciao MarcoGG.

Il fatto è che i DataSet li DEVO utilizzare perchè sono parte dell'esercizio che dobbiamo svolgere!

Altrimenti l'avrei fatto prima..

Quindi, sempre utilizzando il DataSet.. come potrei fare

[gugoXX]

Originariamente inviato da MarcoGG

Non prenderla come una "critica", ma francamente non vedo il perchè di tanta complicazione per fare una Insert su una tabella sola.
Il fatto che i DataSet siano il cuore di ADO.NET non significa che sia sempre obbligatorio farne uso.
Provato con un semplicissimo SqlCommand ?
http://www.codeproject.com/KB/databa...in_csharp.aspx

quoto. Connection e Command e se proprio ci si deve divertire si pilotano le Transaction.

[MarcoGG]

Originariamente inviato da J0k3r91

Ciao MarcoGG.

Il fatto è che i DataSet li DEVO utilizzare perchè sono parte dell'esercizio che dobbiamo svolgere!

Altrimenti l'avrei fatto prima..

Quindi, sempre utilizzando il DataSet.. come potrei fare

Allora assicurati di eseguire l'AcceptChanges() sul DataSet ( o DataTable ) interessato, e poi esegui l'Update :
http://msdn.microsoft.com/it-it/libr...3x(VS.80).aspx

Il fatto che dichiari nel tuo post iniziale che il codice C# gira senza errori, ma a DB "non fa niente", mi fa pensare ad una dimenticanza di questo genere...

[MarcoGG]

Originariamente inviato da gugoXX

e se proprio ci si deve divertire si pilotano le Transaction.

E ri-quoto. Certo, per chi ha uno strano concetto di "divertimento"...

[nuovoUtente86]

Spero che sia un esercizio scolastico e non universitario, perchè programmare ad un solo livello, diciamo 1+ un wrapper, non è proprio il massimo, gestendo di fatto la persistenza dallo strato presentazione.

[Kralizek]

Originariamente inviato da nuovoUtente86

Spero che sia un esercizio scolastico e non universitario, perchè programmare ad un solo livello, diciamo 1+ un wrapper, non è proprio il massimo, gestendo di fatto la persistenza dallo strato presentazione.

al corso di DB abbiamo fatto le peggio porcate dal punto di vista della separazione degli strati proprio perché era un esame di DB e non di Ingegneria del Software o Architetture Software

(resta cmq una porcata eh)

[J0k3r91]

Originariamente inviato da nuovoUtente86

Spero che sia un esercizio scolastico e non universitario, perchè programmare ad un solo livello, diciamo 1+ un wrapper, non è proprio il massimo, gestendo di fatto la persistenza dallo strato presentazione.

Sisi è solo a livello scolastico superiore, non universitario

[J0k3r91]

Originariamente inviato da MarcoGG

Allora assicurati di eseguire l'AcceptChanges() sul DataSet ( o DataTable ) interessato, e poi esegui l'Update :
http://msdn.microsoft.com/it-it/libr...3x(VS.80).aspx

Il fatto che dichiari nel tuo post iniziale che il codice C# gira senza errori, ma a DB "non fa niente", mi fa pensare ad una dimenticanza di questo genere...

Ho aggiunto l'AcceptChanges() e infine l'Update() al programma, perchè precedentemente non le avevo messe.. continua comunque a non fare un bel niente!

Non so dove andare a parare..

[tomminno]

Originariamente inviato da MarcoGG

E ri-quoto. Certo, per chi ha uno strano concetto di "divertimento"...

Personalmente ritengo i Dataset qualcosa di morto con VS2003.
Generics prima e Linq poi li hanno resi decisamente superati come tecnica di programmazione.

[gugoXX]

Originariamente inviato da tomminno

Personalmente ritengo i Dataset qualcosa di morto con VS2003.
Generics prima e Linq poi li hanno resi decisamente superati come tecnica di programmazione.

Quoto.

[MarcoGG]

Originariamente inviato da tomminno

Personalmente ritengo i Dataset qualcosa di morto con VS2003.
Generics prima e Linq poi li hanno resi decisamente superati come tecnica di programmazione.

Bah, mi sembra un po' "fortina" come affermazione.
Chi ha imparato a sfruttare le potenzialità dei DataSet penso non sia molto d'accordo.
Sarà che io resto sempre scettico, e abbastanza "divertito" di fronte ad affermazioni come queste, se si rimane nel contesto italiano, dove vai ad un corso e senti il docente di turno dire "...è una tecnica di sviluppo ormai superata e... blah blah blah...", poi vai a fare un colloquio in una signora azienda, almeno sulla carta, e ti senti dire che hanno bisogno di un tizio che faccia classi in Java o .NET, che devono processare "tracciati record" in formato testo, che escono dal gestionale, al quale ovviamente nessuno vuole mettere mano, e che è scritto... in Cobol.

[nuovoUtente86]

I Dataset saranno effettivamente funzionali e produttivi soprattutto per programmatori poco esperti, ma di certo non sono il miglior esempio( soprattutto in ambito di flessibilità, scalabilità e riutilizzo) di programmazione.

[MarcoGG]

Originariamente inviato da J0k3r91

Ho aggiunto l'AcceptChanges() e infine l'Update() al programma, perchè precedentemente non le avevo messe.. continua comunque a non fare un bel niente!

Non so dove andare a parare..

Ma l'Update l'hai fatto correttamente come nell'esempio alla pagina Msdn che ti ho linkato ?

[tomminno]

Originariamente inviato da MarcoGG

Bah, mi sembra un po' "fortina" come affermazione.
Chi ha imparato a sfruttare le potenzialità dei DataSet penso non sia molto d'accordo.

Il tempo che perdi a creare un dataset tipizzato con l'editor fornito da VS2005 in poi fa passare ogni voglia di utilizzarli (con Linq poi non se ne parla proprio).
Un Dataset non tipizzato è un incubo da gestire in un applicativo di una certa complessità, non sai mai chi ci ha messo le mani sopra e finchè non arrivi a spulciare la query di lettura e tutta l'elaborazione che c'è stata fatta sopra non sai cosa c'è dentro. Proprio la condizione ideale per qualunque business layer.

Mi sta capitando in questi giorni di mettere mano ad un progetto corposo (spacciato per essere in .NET 3.5) che fa uso esclusivo di Dataset non tipizzati in ogni punto ed è tutto un andare a cercare l'origine del dataset per sapere con cosa è stato valorizzato e successivamente da chi viene elaborato e tutto questo solo per conoscere cosa può esserci dentro quella scatola nera. Ma nessuno mi garantisce che una modifica alla query di partenza o qualche punto a valle non faccia poi schiantare il software in un punto remoto solo perchè non c'è più l'informazione che cercavo, stai sicuro che non riceverai nessun errore in compilazione e probabilmente anche l'Unit Test non ti porrà al riparo dagli errori, dovresti confidare nei test di integrazione (di difficile realizzazione se i punti da testare hanno diversi componenti che li separano).
Metti poi che in un database aziendale leggi con Viste e scrivi con Stored,
che non sono impiegabili nei webservice, a meno di non dare per scontato che il client sia in .NET e che chi sviluppa il client vada a spulciare il sorgente del webservice solo per capire cosa gli è stato ritornato.

Ce n'è abbastanza per relegarli al passato.

[MarcoGG]

Originariamente inviato da J0k3r91

Ho aggiunto l'AcceptChanges() e infine l'Update() al programma, perchè precedentemente non le avevo messe.. continua comunque a non fare un bel niente!

Aggiungo un piccolo esempio ( con Access, per Sql basta cambiare i relativi oggetti del provider di dati opportuno e ovviamente la CN... ).
La tabella sul DB è "tblFilm".

> Dichiarazioni :

        private OleDbDataAdapter DA = new OleDbDataAdapter(sqlSelect, CN);
        private DataSet DS = new DataSet();

Dove sqlSelect è una semplice "SELECT * FROM tblFilm".
CN è la Connection e DS è un semplice DataSet, quindi inutile scomodare altri oggetti, metodi strani, ecc. per gestire una tabella...

> Fill del DataSet ( viene fatto una volta sola all'avvio dell'applicazione ) e sua rappresentazione su un DataGridView :

            DA.Fill(DS);
            DataGridView1.DataSource = DS.Tables[0];

> Aggiungo una nuova Row :

            DataRow nuovaRiga = DS.Tables[0].NewRow();
            int nuovoID = Convert.ToInt32(DS.Tables[0].Compute("MAX(ID)", null)) + 1;
            nuovaRiga["ID"] = nuovoID;
            nuovaRiga["TITOLO"] = "Titolo";
            nuovaRiga["ANNO"] = 2010;
            nuovaRiga["GENERE"] = "Genere";
            nuovaRiga["RATING"] = 5;
            nuovaRiga["TRAMA"] = "Trama";
            nuovaRiga["LOCANDINA"] = "Locandina";
            DS.Tables[0].Rows.Add(nuovaRiga);

            if(DS.HasChanges()==true)
            {
                using(OleDbCommandBuilder CB = new OleDbCommandBuilder(DA))
                {
                    DA.UpdateCommand = CB.GetUpdateCommand();
                    DA.InsertCommand = CB.GetInsertCommand();   
                    DA.DeleteCommand = CB.GetDeleteCommand();
                    DA.Update(DS);
                }
            }
            DS.AcceptChanges();
            MessageBox.Show("Modifiche Salvate");

- nuovoID lo calcolo al momento dal DS stesso.
- Ovviamente anche qui sostituire con SqlCommandBuilder ecc...

Perciò, come già detto, niente di trascendentale.
Non so se la complessità della tua impostazione ( definizione di oggetti e metodi vari... ) faccia parte dell'esercizio.
Se l'unico requisito è "usate un DataSet", qui hai forse l'esempio più immediato che ti si possa fornire.