Tag: SQL

WP7 – Database tip

Jednym z najbardziej rozpowszechnionych błędów związanych z aplikacjami na WP7 korzystającymi z bazy danych jest błąd inicjowania tabel. Objawiał się on informacją o nieistniejących tabelach w momencie gdy przy tworzeniu bazy nie zostały do niej dodane żadne wpisy. Okazuje się, że po zainstalowaniu aktualizacji WP 7.1.1 błędu tego nie udało mi się już zreprodukować. Tak to jest, gdy posty zalegają w kolejce i nie zawsze jest czas, żeby na spokojnie je opisać :)

Niemniej jednak – jeżeli tworzymy bazę danych warto do niej dodać przykładowy wpis (najlepiej do dodatkowej, fakeowej tabeli). Dzięki temu silnik SQL CE poprawnie zainicjuje wszystkie tabele co pozwoli uniknąć problemu nieistniejących tabel. Dlaczego? Ponieważ nawet jeżeli błąd jest poprawiony w nowych uaktualnieniach, to nie mamy grawancji, że każdy użytkownik kożysta z najnowszej wersji systemu (dystrybucja uaktualnień u operatorów niestety różnie trwa, szczególnie w przypadku telefonów z USA brandowanych przez AT&A).

Inny problem, na który chciałbym zwrócić uwagę jest dużo bardziej prozaiczny. Chodzi o sposób eksponowania tabel w klasie kontekstu bazy danych. Przyzwyczajenie do właściwości (properties) okazuje się tu niestety zabójcze dla projektu.

Wyobraźmy sobie poniższy kod:

1
2
3
4
5
6
7
8
9
public class SampleDataContext : DataContext
{
	public SampleDataContext(string connectionString)
		: base(connectionString)
	{
	}
 
	public Table<SampleEntry> DataEntries { get; set; }
}

Okazuje się, że po jego uruchomieniu każda próba odwołania się do tabeli otrzymujemy błąd jak na poniższym screenie (Value can not be null):

Okazuje się, że w takim przypadku rozwiązanie zakrawa wręcz o banał, ponieważ wystarczy usunąć dodaną przez nas podświadomie deklarację gettera i settera czyli { get; set; } przy definicji tabeli – zamiast propercji powinna ona być zwykłym polem, o czym warto pamiętać, bo może wam to zaoszczędzić ładny kawałek czasu – w moim przypadku ta “pomyłka” kosztowała 3 godziny :)

 


Prawda o SqlCommand.Parameters

Czy zastanawialiście się kiedyś jak dodawać parametry do SqlCommand? Klasa ta zawiera pole Parameters typy SqlParameterCollection, na którym możemy wykonać między innymi metodę AddWithValue(string, object). W internecie jak i w dokumentacji w nazwach parametrów na początku jest zawsze użyty znak “@”.

Przy okazji jednego z projektów musiałem odpowiedzieć sobie na pytanie: Czy muszę zadbać o “@” przy nazwie parametru? Nie zastanawiając się długo postanowiłem, zgodnie duchem empiryzmu, sprawdzić co się stanie w poszczególnych sytuacjach.

Baza danych.

Dla testów mała baza danych z jedną procedurą pobierającą dwa parametry:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE DATABASE SqlCmdParametersTest
USE [SqlCmdParametersTest]
CREATE PROCEDURE [dbo].[spTest]
	@Param1 INT,
	@Param2 INT
AS
BEGIN
	SET NOCOUNT ON;
	SELECT
 		@Param1 Col1,
		@Param2 Col2END
GO
-- TEST
EXEC [dbo].[spTest] 1, 2
EXEC [dbo].[spTest] @Param1=1, @Param2=2
EXEC [dbo].[spTest] @Param2=1, @Param1=2

Aplikacja testowa

Teraz nie pozostaje nic innego jak przygotować małą aplikację konsolową, która skorzysta z tej procedury. Wiadomo, że podstawowym sposobem dodawania parametrów jest użycie “@” na początku nazwy, zatem będzie to pierwszy sposób użycia. Jako drugi przypadek weźmiemy parametr bez tego znaku. Czy to wszystkie możliwości? Nie – można to przecież jeszcze połączyć i użyć raz z “@” a raz bez – ot tak, żeby było trudniej. Zatem do dzieła:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
using System;
using System.Data;
using System.Data.SqlClient;
 
namespace SqlCmdParametersTest
{
    class Program
    {
        static void Main(string[] args)
        {
            using (SqlConnection sqlConn = new SqlConnection(@"Data Source=localhost;Initial Catalog=SqlCmdParametersTest;Integrated Security=SSPI;Persist Security Info=true"))
            {
                sqlConn.Open();
                using (SqlCommand sqlCmd = new SqlCommand())
                {
                    sqlCmd.CommandType = CommandType.StoredProcedure;
                    sqlCmd.Connection = sqlConn;
                    sqlCmd.CommandText = "[dbo].[spTest]";
 
                    //call with @
                    Console.WriteLine("With @");
                    sqlCmd.Parameters.Clear();
                    sqlCmd.Parameters.AddWithValue("@Param1", 1);
                    sqlCmd.Parameters.AddWithValue("@Param2", 2);
                    using (SqlDataReader reader = sqlCmd.ExecuteReader())
                    {
                        ReadResult(reader);
                    }
 
                    //call without @
                    Console.WriteLine("Without @");
                    sqlCmd.Parameters.Clear();
                    sqlCmd.Parameters.AddWithValue("Param1", 1);
                    sqlCmd.Parameters.AddWithValue("Param2", 2);
                    using (SqlDataReader reader = sqlCmd.ExecuteReader())
                    {
                        ReadResult(reader);
                    }
 
                    //call mixed
                    Console.WriteLine("Mixed");
                    sqlCmd.Parameters.Clear();
                    sqlCmd.Parameters.AddWithValue("@Param1", 1);
                    sqlCmd.Parameters.AddWithValue("Param2", 2);
                    using (SqlDataReader reader = sqlCmd.ExecuteReader())
                    {
                        ReadResult(reader);
                    }
                }
            }
 
            Console.ReadLine();
        }
 
        private static void ReadResult(SqlDataReader reader)
        {
            if (reader.Read())
            {
                Console.WriteLine("Result:");
                Console.WriteLine("{0} {1}", reader["Col1"], reader["Col2"]);
            }
            else
            {
                Console.WriteLine("Result is empty");
            }
        }
    }
}

Wynik dziąłania aplikacji widać na rysunku poniżej:

SqlCmdParametersTestResult

Jak widać wynik jest zgodny z oczekiwaniami – wszystko działa poprawnie, nawet “mix”. Warto jeszcze sprawdzić co dociera do SQL Servera, bo może to on jest tą “sprytną stroną”… Po uruchomieniu SQL Profilera widzimy, że jednak krok ku wygodzie a przede wszystkim swobodzie jest po stronie .NET Framework.

SqlCmdParametersTestSqlProfiler

Wniosek

Z SqlCommand.Parameters można korzystać swobodnie i bez martwienia się o “@” lub jej brak.

Paczka do pobrania


  • O mnie

    Maciej Grabek

    Moje profile na:

    MVP

    Codeguru.pl GoldenLine
    Twitter CodeProject

  • english version
  • Polecam

  • Copyright © Maciej Grabek. All rights reserved.
    Powered by WordPress
    %d bloggers like this: