Kiedy rozważa się dostęp do bazy danych z poziomu urządzenia przenośnego zazwyczaj (skojarzenia to przekleństwo 😉 ) na myśl przychodzi wersja Compact SQL Serwera. W większości przypadków jest to właściwy trop, niemniej obecnie urządzenia coraz częściej wyposażone są w Wi-Fi, co daje nowe możliwości, jeżeli chodzi o przechowywanie przez nie danych. Tak wyposażone mogą bowiem skorzystać ze zwykłego SQL-a, z całym wachlarzem dobrodziejstw, jakie posiada używana wersja. I o tym, jak z poziomu urządzenia (wyposażonego w Win CE i najpewniej także Win Mobile) dostać się do SQL-a, będzie niniejszy wpis.

Wydawałoby się, że sprawa jest właściwie prosta, wystarczy chociażby taki kod:

using System;
using System.Data;
using System.Data.SqlClient;

namespace WinCeDevice
{
	public partial class WinCeDevice : Form
	{
		public WinCeDevice ()
		{
			InitializeComponent();
		}

		private void SqlServerTest()
		{
			string ConnectionString =
				@"Persist Security Info=False;Data Source=ateny;Initial Catalog=master;" +
				@"User ID=sa;Password=s3cr3t!";
			using (SqlConnection Connection = new SqlConnection(ConnectionString))
			{
				Connection.Open();
				SqlCommand cmd = new SqlCommand("select name from sys.databases", Connection);
				SqlDataReader reader = cmd.ExecuteReader();
				while (reader.Read())
				{
					txtLog.Text += reader[0] + Environment.NewLine;
				}
				reader.Close();
			}
		}

		private void btnTest_Click(object sender, EventArgs e)
		{
			SqlServerTest();
		}
	}
}

Niestety przy próbie kompilacji napotykamy na problem z przestrzenią nazw System.Data.SqlClient, którą kompilator kwestionuje. To oczywiście prosta sprawa – wystarczy ręcznie dodać referencję do stosownej biblioteki i projekt już się kompiluje. Pozostaje go zatem uruchomić.

I tu musimy mieć dużo szczęścia, albowiem teoretycznie Visual Studio (testowałem na 2008) powinno umieścić (deploy) wszystkie niezbędne do pracy aplikacji elementy. Niestety – pomimo obwieszczenia przez VS sukcesu umieszczania aplikacji na urządzeniu – próba połączenia z serwerem SQL i wykonania zapytania kończy się niepowodzeniem. Debbuger informuje zaś: Missing method Exception {„Can’t find PInvoke DLL ‚dbnetlib.dll’.”} – wygląda na to, że Visual Studio inaczej rozumie sukces niż reszta świata. Spojrzenie na komunikat przez Google prowadzi na szczęście do rozwiązania, choć pomimo wskazówek, nie jest ono takie proste w zastosowaniu.

Sugestią jest, aby pobrać odpowiedni dla urządzenia pakiet CAB i zainstalować go na nim ręcznie. Rzecz w tym, że w lokalizacji C:\Program Files\Microsoft Visual Studio 9.0\SmartDevices\SDK\SQL Server\Client\v2.0 takich pakietów jest 20. Trzeba zatem sprawdzić, jakim systemem dysponuje urządzenie – moje dysponowało Win CE 6.0. Niestety odpowiadającego mu folderu w powyższej lokalizacji nie było. Były za to WCE400 i WCE500. Logicznym wydawało się skorzystać z wyższej wersji licząc na zgodność systemu o wyższym numerze z oprogramowaniem z systemu wcześniejszego (jak się okazało, było to słuszne przypuszczenie).

Należało jeszcze poznać, jakim procesorem dysponuje urządzenie (Start -> Settings- Control Panel -> System, zakładka General). Moim był ARM, zatem z dostępnych folderów wybrałem ARMV4I. Pozostało ustalić, który z 6 plików CAB w nim umieszczonych, jest tym właściwym. Po sprawdzeniu, które zawierają dbnetlib.dll, na placu boju pozostały trzy pliki, z których dwa miały dodatkowe człony w nazwie: phone i ppc. Ponieważ moje urządzenie nie było ani telefonem, ani Pocket PC (takie rozszyfrowanie skrótu się nasuwało), pozostało użyć pliku trzeciego. Po umieszczeniu go na urządzeniu (w My Documents) i zainstalowaniu z jego poziomu (dwuklikiem) przyszła pora na ponowne uruchomienie aplikacji. Tym razem pięknie zaprezentowała spis baz z serwera SQL umieszczonego w sieci.

Więcej forteli nie było już potrzebne, powyższe wystarczyły.