Malý kapesní WiFi terminál

se čtečkami EAN a RFID uvnitř

Komunikace čtečky a SQL Windows | Linux

Připojení 1 SQL server : N čteček

Připojení 1x SQL Server : 1 až 100 čteček

Tento příklad popisuje situaci [1:N], kdy na jeden SQL Server je připojeno 100 a více čteček. Např. pro sběr dat z výroby, kde každé pracoviště je vybaveno čtečkou. Data jsou online předávaná a zpracovaná v reálném čase bez nutnosti osazovat pracoviště terminálem.

Níže jsou popsané dva kroky jak implementovat čtečky pokud chcete používat režim SQL Server.

Krok 1. Služba pro komunikaci se čtečkou

Služba (Service) systému Windows zabezpečuje trvalou komunikaci všech čteček s databázi MS-SQL (V tomto případě není nutné mít spuštěnou uživatelskou aplikaci). Sejmutý kód na čtečce (EAN nebo RFID) volá přímo uloženou proceduru, která získá data z vašeho systému, popřípadě do něj může zapisovat. Výsledek funkce je odeslaný zpět na čtečku. Vzhledem k použité technologii TCP/IP je reakce systému okamžitá.

Je možné použít standardní již hotovou službu (Service) a pouze si upravit SQL uloženou proceduru nebo si vývojáři mohou napsat vlastní. Návody včetně postupů jsou k dispozici. Detail komunikace čtečky eSemafor Lite je zde.

V případě systému Linux a MySQL je situace snadnější. Zde lze použít Daemon se spouštěním v souboru init. Data jsou ukládaná na pozadí do tabulek MySQL.

Služba pro komunikaci se čtečkou a MS-SQL Server

Krok 2. Příklad procedury v MS SQL

Příklad níže uvedené procedury Hello World ukazuje, jak čtečka může komunikovat přímo s databázemi MS SQL. Proměnná @In_String obsahuje data odeslané ze čtečky (EAN nebo RFID kód).


Obecně script může volat select insert, update apod pro konrétní získání informací z databáze. Současně může do tabulky uložit právě prováděnou událost (zdroj, časové razítko, žádost, ID čtečky a pod). Voláním dalších funkcí a příkazů SQL lze vybudovat robustní řešení přímo na míru vašich zákazníků. V případě změn není nutné přepisovat službu. Vše se mění pouze v uložených procedurách.

Na konci je 0.2 sec prodleva, která nahrazuje/simuluje běh reálného scriptu. (např. provádění Select, Insert, Update apod.) Doba odezvy reálného scriptu by neměla být delší jak 0.5 max. 1 sec. Zvyšováním času můžete testovat, jak budou odpovědi fungovat v produkčním prostředí.

Serverová řešení má nespornou výhodu v jednoduchosti implementace, rychlé reakci na případné změny, opravy popř. dovývoje. Není nutné aktualizovat desítky či stovky stanic. To snižuje cenu řešení a rychlost implementace. Pro jednoduché úlohy je možné jako server používat běžnou stanici vybavenou SQL Serverem.