Connecteren met SQL server via C

[Steve04]

Hallo

Eerst en vooral waar ben ik mee bezig:

Ik ben een remote ECG- (elektrocardiogram) monitor aan het ontwerpen. De bedoeling is dat de meetgegevens via internet naar een SQL database gestuurd worden. Een client kan die data terug opvragen en het signaal reproduceren.

Nu mijn vraag:

Ik wil via C# een connectie maken met mijn SQL server. Nu weet ik dat er daarvoor hulpmiddeltjes zijn zoals ODBC,... . Toch wil ik het op een andere manier proberen namelijk via C# maak ik verbinding met poort 1433 via TCP en wil dan gewoon query's onder de vorm van strings: (INSERT INTO .... SELECT FROM....) sturen naar mijn SQL-server. Het opzetten van de TCP-verbinding is al gelukt (gecontroleerd met netstat) maar query's uitvoeren nog niet. Daarom mijn vraag is het wel op deze manier mogelijk ?

Alvast bedankt .

[gorgi_19]

Welke foutmelding geeft hij dan? En Firewall gaat de boel niet blokkeren? SQL Server staat ook geconfigureerd dat hij op deze manier connecties accepteert?

[RobIII]

^ Wat hij zegt.
Los daarvan: dit is niet "the way to go" IMHO; je wil niet dat client-applicaties rechtstreeks queries gaan lopen uitvoeren. Behalve dat 't een behoorlijk sequerity issue is zal 't in de toekomst zeker voor problemen gaan zorgen wanneer je je datamodel wil wijzigen e.d. Wat je beter doet is er een laagje tussen zetten (zoals WCF bijvoorbeeld) en op die manier babbelen met je server zodat je de externe interface gelijk kunt houden bij interne wijzigingen. Dan kun je meteen daar je authenticatie regelen etc. en de nodige validaties uitvoeren voordat je bepaalde data gaat verwerken (insert/update/delete) of retourneren (select). Hoe voorkom je bijvoorbeeld dat ik een select op je datatabel doe met een where client_id = X terwijl ik client Y ben?

Los daarvan vraag ik me af of dit soort data niet veel beter op een andere manier opgeslagen kan worden i.p.v. een RDBMS.

[ Voor 7% gewijzigd door RobIII op 01-11-2011 18:59 ]

[D-Raven]

Steve04 schreef op dinsdag 01 november 2011 @ 18:46:
Hallo

Eerst en vooral waar ben ik mee bezig:

Ik ben een remote ECG- (elektrocardiogram) monitor aan het ontwerpen. De bedoeling is dat de meetgegevens via internet naar een SQL database gestuurd worden. Een client kan die data terug opvragen en het signaal reproduceren.

Nu mijn vraag:

Ik wil via C# een connectie maken met mijn SQL server. Nu weet ik dat er daarvoor hulpmiddeltjes zijn zoals ODBC,... . Toch wil ik het op een andere manier proberen namelijk via C# maak ik verbinding met poort 1433 via TCP en wil dan gewoon query's onder de vorm van strings: (INSERT INTO .... SELECT FROM....) sturen naar mijn SQL-server. Het opzetten van de TCP-verbinding is al gelukt (gecontroleerd met netstat) maar query's uitvoeren nog niet. Daarom mijn vraag is het wel op deze manier mogelijk ?

Alvast bedankt .

Via TCP? Ga jij zelf in het native protocol praten waarin die database server communiceert? Doe niet zo naief. Gebruik gewoon de tools die ervoor zijn.
.Net heeft een legio aan mogelijkheden om met database servers te communiceren, doe jezelf een plezier en ga het wiel niet opnieuw uitvinden.
Als je op de meest low level manier wilt communiceren, gebruik dan SqlConnection met DataReaders e.d. of ga voor de wat moderne optie zoals bijvoorbeeld LinqToSql. Dan heb je maximale controle over de queries die
je over de lijn gooit.

Natuurlijk zijn er nog meer mogelijkheden, alleen daarvoor zul je nog meer moeite en tijd moeten investeren om deze jezelf eigen te maken. De voorbeelden die ik nu genoemd heb zijn naar mijn mening de meest eenvoudige opties om mee te beginnen.

Edit: mocht je met SqlConnection e.d. aan de slag gaan, vergeet dan vooral niet je in te lezen in PreparedStatements. SqlConnection toch te low level voor je? Gebruik dan LinqToSql oid.

[ Voor 5% gewijzigd door D-Raven op 01-11-2011 19:02 ]

[RobIII]

D-Raven schreef op dinsdag 01 november 2011 @ 18:58:
[...]


Via TCP? Ga jij zelf in het native protocol praten waarin die database server communiceert?

Dat had ik nog niet eens in de gaten! Nu ik de topicstart opnieuw lees krijg ik inderdaad heel erg de vibe dat er ergens een new Socket(...) gebruikt wordt

Dan ben ik het inderdaad met dooie raaf eensch dat je gewoon new SqlConnection(...) moet gebruiken. Zie daarvoor de System.Data.SqlClient documentatie.

Maar ik blijf bij mijn eerste post dat je heel SQL server niet eens moet (willen) exposen.

>> Stop hier met lezen <<
Het protocol is overigens wél gedocumenteerd (in hoeverre dat compleet is weet ik niet). Maar als je dat gaat gebruiken heb je verdomd sadomasochistische trekjes

[ Voor 44% gewijzigd door RobIII op 01-11-2011 19:09 ]

[D-Raven]

RobIII schreef op dinsdag 01 november 2011 @ 19:02:
[...]

Dat had ik nog niet eens in de gaten! Nu ik de topicstart opnieuw lees krijg ik inderdaad heel erg de vibe dat er ergens een new Socket(...) gebruikt wordt

Jij en ik hadden dezelfde vibe

[Steve04]

Eigenlijk wou ik dit op deze manier eens testen omdat het stukje hardware die het ECG-signaal meet een microcontroller is die beschikt over een ethernet stack. Een .Net framework heb ik niet alles is in C te doen. Een TCP verbinding opzetten geen probleem maar dan hoe voer ik query's uit op mijn SQL database, ik dacht gewoon string verzenden in de vorm van INSERT INTO, SELECT, ... .
Vandaar dat ik dit eens wou uitproberen via mijn laptop het is namelijk hetzelfde principe.

Inderdaad ik gebruik sockets, nu lijkt een sql database ook niet echt de beste oplossing zijn er misschien suggesties ?

[ Voor 4% gewijzigd door Steve04 op 01-11-2011 19:25 ]

[RobIII]

Steve04 schreef op dinsdag 01 november 2011 @ 19:21:
Een .Net framework heb ik niet alles is in C te doen

Volgens je topictitel niet

Steve04 schreef op dinsdag 01 november 2011 @ 19:21:
Inderdaad ik gebruik sockets, nu lijkt een sql database ook niet echt de beste oplossing zijn er misschien suggesties ?

Flat file? Binary file? Die kun je dan 'transferen' middels HTTP/FTP/whocares. En nog 1001 andere mogelijkheden... Wat had je zelf al bedacht? at heb je wél tot je beschikking?

[ Voor 10% gewijzigd door RobIII op 01-11-2011 19:33 ]

[Steve04]

Welja dit is één van de mogelijkheden zelf had ik gedacht om met MYSQL te werken mits de microcontroller met PHP overweg kan. LinqToSql is dan weliswaar niet meer mogelijk maar er zijn andere mogelijkheden (ODBC).

Nu een binary file gebruiken is zeker ook niet slecht alleen twijfel ik nu wat het beste is.

(Misschien het melden waart het is voor mij belangrijker dat het uitwisselen van gegevens snel gebeurt om zoveel mogelijk "real time" te halen het aantal personen die het signaal tegelijk willen monitoren zal nooit veel zijn)

[D-Raven]

Wat je dan ook kan doen, is zoals RobIII al voorstelt, laat je ECG applicatie een data bestand neerzetten op een voor jou bekende locatie, en schrijf dan een andere applicatie welke dit bestand oppakt en naar een database wegschrijft (die andere applicatie draait dan op de pc oid waar je je bestand neerzet)

[Steve04]

Bedankt voor de reacties tot nu toe.

Op basis van jullie input heb ik volgend voorstel:
De microcontroller neemt twee taken voor zich: het samplen van het signaal en dit in een file "gieten" en neemt de rol op zich als server.
De ethernet stack ondersteunt Berkeley sockets dus ben ik van plan een Berkeley TCP server op te zetten. Gelukkig zijn er wat demo bestanden meegeleverd die dit al deels implementeren + uitleg.
De bedoeling is nu dat de server luistert naar binnenkomende client connecties, die deze vervolgens accepteert
zodat data uitgewisseld kan worden. In principe zou ik het zo kunnen programmeren dat voor elke geconecteerde client de server gewoon de data doorstuurt. Daarnaast moet de client ook wat parameters (i.v.m ECG-signaal en instellingen) van de server ontvangen. Nu zou ik dit implementeren in commando's die de server interpreteerde en de nodige response op terugstuurt. Wat is jullie mening ?

[RobIII]

Steve04 schreef op dinsdag 01 november 2011 @ 20:42:
Wat is jullie mening ?

Mja, leuk globaal en weinig concreet verhaaltje. Als je 't voor jezelf helder hebt: gaan! Waar wacht je op?
Zo niet: wat wil je van ons weten?

Ik zou eens kijken of je niet een laagje of 2 "hoger" dan "Berkeley sockets" kunt gaan; als je je echt op dit niveau met bits en bytes moet gaan bezighouden ben je natuurlijk weinig bezig met je daadwerkelijke probleem (lees: business (logica)). Als 't écht zo low-level-kan-niet-anders moet; tja, so be it. Als je een http wrapper kunt gebruiken of weet-ik-het dan zou ik daar eerst eens naar kijken. Een, bijvoorbeeld, PUT of POST of weet-ik-het is al zoveel beter dan (chunked) transfers zelf gaan lopen administreren, met sockets te fröbelen etc.

Overigens zou je in zo'n file natuurlijk ook in de 'header' bijvoorbeeld de instelling(en)/afregeling/parameters/weet-ik-veel van 't apparaat kunnen opslaan (en relateren aan de ontvangen file op één of andere manier); zéker als je die later nog nodig hebt. Als de metainfo enkel tijdens ontvangst interessant is (maw: "non-persistent") is 't natuurlijk andere koek. Moet je de metainfo nog hebben dan kun je 't dus net zo goed meteen in die file mikkeren lijkt me. Ik ken natuurlijk (inhoudelijk) je project niet maar anders dan de 2 commando's
* "joehoe, ik ben Pietje en mijn passwd is f00b4r"
en
* "hier, een file, veel plezier ermee, kthnxbye"
hoeft de server natuurlijk (kort door de bocht) niet te ondersteunen. KISS

Maar even voor de zekerheid: we hebben 't dus over C en niet C#? Want dan kan ik je (toch wel érg verwarrende in dit geval) topictitel even fix0ren.

[ Voor 40% gewijzigd door RobIII op 01-11-2011 23:41 ]

[matthijsln]

Steve04 schreef op dinsdag 01 november 2011 @ 20:42:
Bedankt voor de reacties tot nu toe.

Op basis van jullie input heb ik volgend voorstel:
De microcontroller neemt twee taken voor zich: het samplen van het signaal en dit in een file "gieten" en neemt de rol op zich als server.
De ethernet stack ondersteunt Berkeley sockets dus ben ik van plan een Berkeley TCP server op te zetten. Gelukkig zijn er wat demo bestanden meegeleverd die dit al deels implementeren + uitleg.
De bedoeling is nu dat de server luistert naar binnenkomende client connecties, die deze vervolgens accepteert
zodat data uitgewisseld kan worden. In principe zou ik het zo kunnen programmeren dat voor elke geconecteerde client de server gewoon de data doorstuurt. Daarnaast moet de client ook wat parameters (i.v.m ECG-signaal en instellingen) van de server ontvangen. Nu zou ik dit implementeren in commando's die de server interpreteerde en de nodige response op terugstuurt. Wat is jullie mening ?

Dit laatste (direct naar een socket schrijven) lijkt me in prima oplossing.

Wat wel iets om aan te denken is dat als je data van de ECG aan het samplen bent je waarschijnlijk de sampling rate moet limiteren om niet de send buffer te overschrijden en de juiste timecode bij een sample te kunnen bepalen in de client. Zorg er ook voor dat je wel meerdere samples in één packet / send() call verstuurt (indien de TCP stack Nagle's algoritme implementeert hoef je er niet perse op te letten, maar zal wel tot een delay leiden).

@RobIII dit soort dingen is met een HTTP abstractie mogelijk iets lastiger of minder zichtbaar en minder geschikt voor live streaming. Vooral bij een microcontroller moet je denk niet zoveel voorstellen van beschikbare libraries e.d., alhoewel dit natuurlijk afhangt van het soort microcontroller.

Je kan je ECG monitor vergelijken hoe een GPS ontvanger werkt (of de communicatie nou over een COM poort, Bluetooth of ethernet connectie gaat maakt niet zoveel verschil). De client zet de verbinding op, en de ontvanger begint direct NMEA sentences te sturen. Sommige ontvangers kan je ook commando's geven om instellingen te veranderen.

[Steve04]

Jullie hebben gelijk een paar commando's invoeren om parameters te krijgen maakt het geheel onnodig ingewikkeld. Ik kan deze gewoon in de header stoppen.

MatthijsIn daar had ik al aan gedacht: telkens een sample (2bytes) versturen met een 40 byte TCP header is niet bepaald efficiënt dus ga ik de data eerst buffer tot een bepaalde lengte en dan versturen.
Mijn grootste zorg gaat timing zijn: samplen + ethernet functies afhandelen op een microcontroller die op 25MHz clockt, wordt een uitdaging.

Alvast bedankt voor de reactie en resultaten zal ik zeker posten.

(Wat betreft de topictitel momenteel heeft het niks meer te maken met SQL en C# en is het dus C, u mag de titel gerust veranderen of het topic ergens anders deponeren)