[VB.NET] Passare parametro query come "IS NOT NULL"

[ASSTO]

Ciao a tutti,
sto ancora lavorando al mio programma (http://www.hwupgrade.it/forum/showthread.php?t=2160107) e mi sono piantato durante l'ottimizzazione della parte relativa l'archivio.

Nel form di visualizzazione delle prove avevo implementato un pulsante per filtrare le stesse (visualizzate in una dataGridView) in funzione del contenuto di tre textboxes. Avevo gestito il tutto eseguendo una query su un tableAdapter ma siccome ho letto in giro di un certo "SQL Inject", ho deciso di ricreare il codice utilizzando una query parametrica però ho un problema: una delle tre textboxes potrebbe essere vuota. In tal caso con il sistema precedente avrei inserito "WHERE (campo IS NOT NULL)" tramite concatenazione di stringhe...come posso ottenere lo stesso risultato con OleDbParameter?

[ASSTO]

Up

[MarcoGG]

Originariamente inviato da ASSTO

...
In tal caso con il sistema precedente avrei inserito "WHERE (campo IS NOT NULL)" tramite concatenazione di stringhe...come posso ottenere lo stesso risultato con OleDbParameter?

Direttamente non puoi.
Ma è possibile farlo "indirettamente". In poche parole, una tecnica possibile, e neanche tanto impegnativa è quella di creare dei propri parametri che, in un certo senso, "incorporano" gli OleDbParameters.
Il che significa che andrò a creare un OleDbParameter solo quando lo riterrò opportuno, ossia, in questo caso, solo se il contenuto di una TextBox non è Stringa vuota. Perciò il mio Parametro potrà essere a seconda del caso, sia un OleDbParameter, sia una semplice stringa, che in questo caso specifico sarà = " IS NOT NULL ".

Esempio :

        Dim strSql As String = ""

        Dim CMD As New OleDb.OleDbCommand

        'Parametri SELECT :
        Dim param1 As String
        If TextBox1.Text = "" Then
            param1 = " IS NOT NULL "
        Else
            CMD.Parameters.Add("@param1", OleDb.OleDbType.VarChar)
            CMD.Parameters("@param1").Value = TextBox1.Text
            param1 = "=@param1"
        End If

        Dim param2 As String
        If TextBox2.Text = "" Then
            param2 = " IS NOT NULL "
        Else
            CMD.Parameters.Add("@param2", OleDb.OleDbType.VarChar)
            CMD.Parameters("@param2").Value = TextBox2.Text
            param2 = "=@param2"
        End If

	'...

        Dim paramN As String
        If TextBoxN.Text = "" Then
            paramN = " IS NOT NULL "
        Else
            CMD.Parameters.Add("@paramN", OleDb.OleDbType.VarChar)
            CMD.Parameters("@paramN").Value = TextBoxN.Text
            paramN = "=@paramN"
        End If

        strSql = "SELECT * FROM nomeTabella" & _
                   " WHERE nomeCampo1" & param1 & _
                   " AND nomeCampo2" & param2 & _
		 '...
		 '... 
                   " AND nomeCampoN" & paramN

        CMD.CommandText = strSql
        CMD.Connection = CN

        CN.Open()
        Dim RDR As OleDb.OleDbDataReader = CMD.ExecuteReader()
        While (RDR.Read())

            'Processo Reader...
            '...

        End While

	'...

[ASSTO]

Grazie mille Marco, funziona!

Posso chiederti come mai l'utilizzo della @ come primo carattere nel nome dei parametri?

Visto che ci sono, sfrutto ancora la tua conoscenza (e, soprattutto, la tua disponibilità!!!): l'interfaccia grafica della mia applicazione è formata da un form MDI che contiene tanti form figli. L'interrogativo è questo: come faccio a far si che premendo il tasto "stampa" nella barra degli strumenti del form padre il programma stampi un documento diverso a seconda del form attivo in quel momento?

E' la prima volta che programmo con un form MDI e non ho la più pallida idea di come funzioni questa cosa...

[MarcoGG]

Originariamente inviato da ASSTO

Grazie mille Marco, funziona!

Certo che funziona.

Originariamente inviato da ASSTO

Posso chiederti come mai l'utilizzo della @ come primo carattere nel nome dei parametri?

Sai che non ho mai creato named parameters senza "@" ?
E' una convenzione tipica dell'Sql ( Stored Procedures, Triggers, ... ), che a me piace tanto. Prova a rileggere una query di inserimento o di update con 50 named parameters che si chiamano come i campi, e che non iniziano per "@", e vedrai che... ti rispondi da solo.

Originariamente inviato da ASSTO

Visto che ci sono, sfrutto ancora la tua conoscenza (e, soprattutto, la tua disponibilità!!!): l'interfaccia grafica della mia applicazione è formata da un form MDI che contiene tanti form figli. L'interrogativo è questo: come faccio a far si che premendo il tasto "stampa" nella barra degli strumenti del form padre il programma stampi un documento diverso a seconda del form attivo in quel momento?

E' la prima volta che programmo con un form MDI e non ho la più pallida idea di come funzioni questa cosa...

Se si parla di Form semplici :

        Dim nomeFormAttivo As String = Form.ActiveForm.Name
        MsgBox(nomeFormAttivo)

Se si parla di una Form Figlia in un contesto MDI :

        Dim nomeFormAttivoMdiChild As String = Form.ActiveForm.ActiveMdiChild.Name
        MsgBox(nomeFormAttivoMdiChild)

[ASSTO]

Originariamente inviato da MarcoGG

Certo che funziona.



Sai che non ho mai creato named parameters senza "@" ?
E' una convenzione tipica dell'Sql ( Stored Procedures, Triggers, ... ), che a me piace tanto. Prova a rileggere una query di inserimento o di update con 50 named parameters che si chiamano come i campi, e che non iniziano per "@", e vedrai che... ti rispondi da solo.



Se si parla di Form semplici :

        Dim nomeFormAttivo As String = Form.ActiveForm.Name
        MsgBox(nomeFormAttivo)

Se si parla di una Form Figlia in un contesto MDI :

        Dim nomeFormAttivoMdiChild As String = Form.ActiveForm.ActiveMdiChild.Name
        MsgBox(nomeFormAttivoMdiChild)

Scusami...mi sono espresso poco chiaramente! Per "documento" intendevo un PrintDocument!

Relativamente la @...effettivamente hai ragione!

[MarcoGG]

Originariamente inviato da ASSTO

Scusami...mi sono espresso poco chiaramente! Per "documento" intendevo un PrintDocument!

Beh, io ti ho fatto 2 esempi per rilevare il nome del Form attivo al momento.
Ora sai tu come farne uso. Se vuoi lanciare la stampa del PrintDocument sul Form attivo al momento, da un menu posto sulla MDI, userai un codice simile al secondo che ho postato per ricavare il Form Child al momento attivo, e poi stamperai il PrintDocument ad esso associato, se era questo che intendevi...

[MarcoGG]

Rispondo qui a tuo pvt ( ragazzi, c'è già il Forum, perchè mi fate le domande in Pvt ? ).

"Ora il problema:
Attualmente la form principale inizializza l'array, lo riempie con i dati dell'acquisizione, effettua i calcoli e riempie le TB. Come cavolo faccio a far si che alla pressione del pulsante sia l'altra form ad acquisire l'array, elaborarlo e poi ripassare tutto alla form principale?

Abbreviando, sto cercando di capire se sia possibile fare il passaggio di dati tra forms e (se si può) come farlo..."

La risposta è molto semplice. Usa un Array solo, che avrai definito come Public in un Modulo ( o classe statica ). A quel punto potrai farvi accesso da qualsiasi punto del codice.

[ASSTO]

Grazie ancora, sono riuscito a fare il mio grafico e tutto il resto...ma a questo punto mi è nato un altro problema:

Per aggiornare le Textboxes con i dati che ho prelevato nella form del grafico apro quest'ultima con una dichiarazione

public WithEvents grafico as new grafico

solo che se l'utente decide di voler effettuare un'altra acquisizione viene il codice genera un'eccezione del tipo ObjectDisposedException in quanto la form del grafico viene chiusa con me.close().

Ho effettuato una ricerca ma l'unica soluzione che sono riuscito a trovare è quella di non chiudere il form ma di nasconderlo...che per me non va bene perchè così facendo nel grafico i parametri della seconda acquisizione andrebbero ad aggiungersi ai parametri della prima. Un altro metodo sarebbe quello di creare una nuova istanza ma non è possibile effettuare una dichiarazione pubblica all'interno di una routine...che fare?

[ASSTO]

Risolto...delle volte dormo!

Per i posteri che si dovessero trovare nella stessa situazione: prima dichiarate

Public WithEvents nomeVariabile as nomeForm

Poi istanziate con

nomeVariabile = new nomeForm

ogni volta che volete.

Sono le basi ma sono talmente fuso che ho perso un'ora per questa cavolata...

[ASSTO]

Originariamente inviato da ASSTO

Ciao a tutti,
sto ancora lavorando al mio programma (http://www.hwupgrade.it/forum/showthread.php?t=2160107) e mi sono piantato durante l'ottimizzazione della parte relativa l'archivio.

Nel form di visualizzazione delle prove avevo implementato un pulsante per filtrare le stesse (visualizzate in una dataGridView) in funzione del contenuto di tre textboxes. Avevo gestito il tutto eseguendo una query su un tableAdapter ma siccome ho letto in giro di un certo "SQL Inject", ho deciso di ricreare il codice utilizzando una query parametrica però ho un problema: una delle tre textboxes potrebbe essere vuota. In tal caso con il sistema precedente avrei inserito "WHERE (campo IS NOT NULL)" tramite concatenazione di stringhe...come posso ottenere lo stesso risultato con OleDbParameter?

Mi accorgo ora di un problema: dal momento in cui premo il bottone per filtrare i risultati effettuo una query sul database utilizzando un DataReader e con lo stesso popolo la DataGridView modificandone il DataSource della BindingSource...fatto ciò però non riesco più ad ordinare le celle della DGV cliccando sull'header!
Il perchè posso immaginarlo...ma come risolvo? Devo scrivere riga per riga il codice che gestisce l'ordinamento o c'è qualche alternativa?
Secondo me sto facendo un pasticcio tra TableAdapters, stored procedures ecc ecc...

[MarcoGG]

Originariamente inviato da ASSTO

...
...
Secondo me sto facendo un pasticcio tra TableAdapters, stored procedures ecc ecc...

Può dipendere da che tipo di binding hai fatto, ma anche da altro. Da quanto dici quei dati fanno un certo "giro", abbastanza tortuoso, prima di finire in quel DataGridView. Ti rendi conto di quanto sia difficile rispondere fattivamente a domande come queste ?

[ASSTO]

Originariamente inviato da MarcoGG

Può dipendere da che tipo di binding hai fatto, ma anche da altro. Da quanto dici quei dati fanno un certo "giro", abbastanza tortuoso, prima di finire in quel DataGridView. Ti rendi conto di quanto sia difficile rispondere fattivamente a domande come queste ?

Effettivamente...si!!! Me ne rendo conto!

Riformulo la domanda del precedente post: dico male se affermo che la gestione dei dati di un db access è assegnata a due diverse "famiglie di oggetti" (che nel mio intricato schema mentale sarebbero una composta dai TableAdapters, DataAdapters ecc ecc ed un altra dai vari Oledbxxxxx)?

[MarcoGG]

Originariamente inviato da ASSTO

Effettivamente...si!!! Me ne rendo conto!

Riformulo la domanda del precedente post: dico male se affermo che la gestione dei dati di un db access è assegnata a due diverse "famiglie di oggetti" (che nel mio intricato schema mentale sarebbero una composta dai TableAdapters, DataAdapters ecc ecc ed un altra dai vari Oledbxxxxx)?

La risposta è : Sì e No.
Ad esempio, se vuoi semplicemente visualizzare i dati ( quindi non consentendo all'utente Insert/Update/Delete ) in un DataGridView, l'unica cosa che serve è un DataReader.
Se il DGV invece accetta le modifiche dell'utente, basta un DataSet. In questi 2 casi non dovrebbe presentarsi alcun problema di riordinamento sulle colonne del DGV, in quanto si lavora sempre in modalità disconnessa.
Però, ripeto, sono indicazioni di massima. Non conoscendo nulla della struttura del tuo DB e della tua applicazione, posso solo dare indicazioni generiche. Personalmente non amo le "connessioni guidate" di VS, i vari TableAdapter, BindingSource, ecc. Si può fare tutto ugualmente a mano, scrivendo codice, in modo che possa essere rapidamente modificato in caso di cambiamenti a DB ( che comunque non dovrebbero MAI esserci, o in ogni caso dovrebbero essere di minima entità, perchè PRIMA si fa il DB. POI si fa l'applicazione... ).

[ASSTO]

Originariamente inviato da MarcoGG

La risposta è : Sì e No.
Ad esempio, se vuoi semplicemente visualizzare i dati ( quindi non consentendo all'utente Insert/Update/Delete ) in un DataGridView, l'unica cosa che serve è un DataReader.
Se il DGV invece accetta le modifiche dell'utente, basta un DataSet. In questi 2 casi non dovrebbe presentarsi alcun problema di riordinamento sulle colonne del DGV, in quanto si lavora sempre in modalità disconnessa.
Però, ripeto, sono indicazioni di massima. Non conoscendo nulla della struttura del tuo DB e della tua applicazione, posso solo dare indicazioni generiche. Personalmente non amo le "connessioni guidate" di VS, i vari TableAdapter, BindingSource, ecc. Si può fare tutto ugualmente a mano, scrivendo codice, in modo che possa essere rapidamente modificato in caso di cambiamenti a DB ( che comunque non dovrebbero MAI esserci, o in ogni caso dovrebbero essere di minima entità, perchè PRIMA si fa il DB. POI si fa l'applicazione... ).

Sono d'accordissimo sul discorso delle connessioni guidate, ma per un novizio sono parecchio comode...soprattutto il sistema di creazione e modifica delle DataGridViews. Ad esempio, sto ri-scrivendo tutto il codice delle mie form di visualizzazione sostituendo tutti i vari prodotti delle "autocomposizioni" (per dirla alla "Office") con le stored procedures (è questo il nome per definire quanto racchiude i vari OleDbxxxxx, giusto?), solo che mi devo formattare a mano colonna per colonna le DGV...c'è un sistema rapido per farlo?

[MarcoGG]

Originariamente inviato da ASSTO

Ad esempio, sto ri-scrivendo tutto il codice delle mie form di visualizzazione sostituendo tutti i vari prodotti delle "autocomposizioni" (per dirla alla "Office") con le stored procedures (è questo il nome per definire quanto racchiude i vari OleDbxxxxx, giusto?), solo che mi devo formattare a mano colonna per colonna le DGV...c'è un sistema rapido per farlo?

Non capisco il discorso sulle "Stored Procedures". Ma se usi OleDb, hai sotto un DB Access, o cosa ?
Access non supporta nè Stored Procedures, nè Triggers, a meno che tu con "Stored Procedures" non intendi "Stored Queries"...
Secondo me c'è un po' di confusione. Il fatto che tu stia semplicemente usando named parameters su OleDb, non significa che fai uso di Stored Procedures.
La situazione-tipo, ripeto, è quella di avere un DGV associato ad un DataSet tipizzato, e a quel punto la formattazione delle colonne se la va a prendere dal DataSet stesso. Oppure usi un DataReader... Ottieni comunque un funzionamento più flessibile rispetto alle creazioni guidate, che sono agili e rapide, ma poi se devi metterci mano, spesso son dolori.