Några generella frågor...

1. Kan inte din service vara den som sparar ner saker till databasen på det sättet får ju din service reda på vad som ändras och kan puscha den nya infon till registrerade klienter.
2. Ja jag har för mig att det finns något i 2005:an eller om det kommer i det nya 2008:an.
3. Om det bara är en klient så tycker jag nästan öppen, även om det inte blir någon större skillnad om du stänger den eftersom den ligger i connectionpoolen.

Tänk noga när du designar och gör inte prestanda kravet till alltför stor grej i början.
Gör helst en prototyp över arkitekturen på hur det skall fungera innan så kan du snabbt testa din lösning.

En annan fråga varför en databas om det bara är en klient?

Vet inte om denna länk kan erbjuda lite hjälp...
http://www.microsoft.com/sql/technologies/notification/default.mspx

Nickemannen skrev:

Tänk noga när du designar och gör inte prestanda kravet till alltför stor grej i början.
Gör helst en prototyp över arkitekturen på hur det skall fungera innan så kan du snabbt testa din lösning.

Vi har tagit fram en skiss på hur trafiken ska se ut.

Nickemannen skrev:

En annan fråga varför en databas om det bara är en klient?

Vi är tvungna att använda oss av kommunikation som styrs av andra. Alternativet till SQL Databasen är som våran leverantör av ocx-dll'erna rekommenderar Access 2000. Eftersom det är en del som skrivs hela tiden (4+ rader i sekunden) så känns det helt klart stabilast med en sql databas. Dessutom vill vi använda sql reports mm för statistik och annat samt eventuellt knyta ihop det med sharepoint så småningom.

invecklaren skrev:

Vet inte om denna länk kan erbjuda lite hjälp...
http://www.microsoft.com/sql/technologies/notification/default.mspx

Det var vad jag letade efter $5,600 är dock rätt saftigt bara för den funktionen ;)

Antar det får bli en egengjord .net service då...

catz skrev:

Jag behöver skapa en service som håller reda på vissa ändringar osv i en databas. Hur löser man notifieringen till en winform på bästa sätt? Jag vill inte låta min winform ligga och söka i databasen hela tiden av prestandaskäl.

Beroende på protokollet som du använder mellan din winform och services, så kan du skicka events från din services till din winform. Om du använder WCF och typ netTcpBinding som protokoll så är det både enkelt och rellativt bra ur prestandasynpunkt.

Catz skrev:

Kan någon av MS SQL versionerna notifiera min service istället om vissa ändringar sker. Går det lösa med triggers eller nåt? Detta hör väl egentligen hemma i SQL forumet men det känns b att starta två trådar.

I ADO.NET så finns det notficering från databasen inbyggt, och använder du MS SQL 2005 så skickar den ett event från databasen till din .NET applikation att något har hänt i en tabell.

Catz skrev:

Applikationen som ska användas är en winform med 1 användare. Får jag då bäst prestanda med en öppen anslutning eller är det bättre att stänga den efter varje anrop till databasen? Minne / CPU är helt ointressant, det finns mer än jag kan göra av med. Jag behöver bara att det går riktigt ordentligt snabbt!

Nu hänger jag inte med, du vill ha en services som informerar dig om när något händer i databasen, men du har endast 1 program som skall vara kopplat mot den? Du missar nog att berätta hela sanningen här!!!

Jag kan se följande alternativ, du är inte ensam mot databasen och därför bör ditt program använda sig av connectionpooling när du vill kommunicera med databasen (det finns helt enkelt fler program som accessar din databas och de uppskattar säkert inte att du snor en av databasen kopplingar för "alltid".

Alternativ 2 är att du ensam om databasen och då finns det ju liksom ingen anledning att ditt program skall notificeras om något händer i databasen, eftersom ditt program garanterat är det som gör förändringar i databasen.

- Lite mer info hade varit bra, och speciellt då vilka andra program/tjänster är det som kan ändra på data i databasen, och skulle du kunna styra så att dessa alltid gör dessa via en "ändringsservices" eller accessar de ner till databasen direkt från sina respektive program?
- Vad är det för information som du efterlyser eftersom du är intresserad av att det går "blixtsnabbt" för din applikation att få information, är det viktigt att information kommer i "rätt ordning" eller spelar den någon roll om den kommer i en oordning till dig?
- Hur viktigt är det att du verkligen får information till din applikation, vad händer om något meddelanden försvinner på vägen?
- Kan du låsa protokollet till ett .NET förfarande, eller är det så att andra applikationer skrivna i andra språk även skall kunna abonnera på dina förändringar i databasen?

osv osv...

- M

Gladh skrev:

Nu hänger jag inte med, du vill ha en services som informerar dig om när något händer i databasen, men du har endast 1 program som skall vara kopplat mot den? Du missar nog att berätta hela sanningen här!!!

Jag kan se följande alternativ, du är inte ensam mot databasen och därför bör ditt program använda sig av connectionpooling när du vill kommunicera med databasen (det finns helt enkelt fler program som accessar din databas och de uppskattar säkert inte att du snor en av databasen kopplingar för "alltid".

Alternativ 2 är att du ensam om databasen och då finns det ju liksom ingen anledning att ditt program skall notificeras om något händer i databasen, eftersom ditt program garanterat är det som gör förändringar i databasen.

- Lite mer info hade varit bra, och speciellt då vilka andra program/tjänster är det som kan ändra på data i databasen, och skulle du kunna styra så att dessa alltid gör dessa via en "ändringsservices" eller accessar de ner till databasen direkt från sina respektive program?
- Vad är det för information som du efterlyser eftersom du är intresserad av att det går "blixtsnabbt" för din applikation att få information, är det viktigt att information kommer i "rätt ordning" eller spelar den någon roll om den kommer i en oordning till dig?
- Hur viktigt är det att du verkligen får information till din applikation, vad händer om något meddelanden försvinner på vägen?
- Kan du låsa protokollet till ett .NET förfarande, eller är det så att andra applikationer skrivna i andra språk även skall kunna abonnera på dina förändringar i databasen?

osv osv...

- M

Ok jag gör ett nytt försök.

En service för att hålla koll på konfigurationen mellan en gammal vb applikation och en databas. I Denna databasen kommer konfigurationsinstälningar för det som ska in i den riktiga databasen finnas. Den här servicen ska läsa av vb-applikationen kontinuerligt med hjälp av ocx som vi ej kan modifiera.

En service kommer konstant mata in massvis med data i databasen kontinuerligt och då hämta instälningar från inställningsdb'n och mata in rätt många rader i sekunden i informationsdatabasen.

Sedan har vi då vår winform aplikation som är kodad i C#. Denna håller koll på informationen i informationsdatabasen, sorterar, filtrerar, paketerar och skriver ut. Utskrifterna görs med hjälp av sql reports.

Undrar om jag missade något...?

Det är endast mina applikationer som gör ändringarna. VB-programet får datan, vi läser av datan och matar in den i databasen. Vi får givetvis inte missa någon information... då blir det fel och jag har faktiskt funderat på det där med i vilken ordning osv. Det är delvis därför jag är anställd :) Just nu har vi en

select top1 id

som med fördel kan bytas ut mot SCOPE_ IDENTITY. Jag har redan stött på problem när jag bug-fixat den aplikationen i nuvarande form där vi har problem med vilka trådar den hämtar information från. Detta löste jag med ado.net transactions och låste transaktionen till den nuvarande tråden.

Det är väl inte superviktigt att vi får all information men det är viktigt att jag i alla fall får veta att information gått förlorad...

Blev det mer rörigt nu?

Får se om jag har förstått bättre nu :).

Ni skall alltså bygga 2 services och 1 applikation.

- Du har en services som skall läsas av en gammal VB-applikation, och den skall bara läsa/skriva konfigurationsinformation till en databas där man ändrar denna data i en gammal vb-applikation? Och denna information skall användas av er .NET applikation?

- Du har en services som skall skriva in massor med data till en annan databas. Vem kallar på denna services? Var får den sin data ifrån? Är det kritisk data? Vad händer om denna services går ner? Är det denna data som du vill att din .NET applikation skall få reda på?

Sist så har den en winform som skall få den senast datan och presentera den. Kommer den läsa datan beroende på hur det ser ut i konfigurationsdatabasen?

Ursäkta om jag är lite trög, men det är så mycket svårare att se det när man inte sitter framför whiteboarden och någon ritar och berättar.

Men som jag ser det så är det kritiskt att er winform inte missar någon data i sina rapporter, men samtidigt så säger du att det kommer ny data var 1/4 sekund (minst), det betyder att det skall skapas nya rapporter hela tiden, vilket ju knappast någon kan ha glädje av i winformen, man kommer ju inte hinna se rapporetn innan nästa rapport skapas och visa.... :)

select top 1 ID verkar inte vara speciellt säkert, då jag misstänker att ni ligger och pollar databasen för att få fram senast inlaggda ID i databasen, men då ni ligger och pollar så finns det en teoretisk chans att det kommer komma in 2 poster istället för 1 och du kommer att missa en post. I så fall är det bättre att spara undan det senaste ID i din winform och sedan när du pollar så hämtar du alla poster som har ett större ID än det som fanns i din winform, då skulle du få med alla nya poster.

Jag misstänker att du vill att den servicens som skriver ner data till databasen notificerar din winform om att det kommit ny data, så du slipper fråga databasen varje gång. Det kan du enkelt lösa med WCF med duplexchannels, det finns lite andra lösningar också men detta är nog den enklaste. Men om din winform ändå måste hämta data från databasen så hade jag nog hoppat över den biten och kopplat upp winformen mot databasen med hjälp av ADO.NET och satt upp ett event som notificerat din winform när något hade hänt i den tabellen som du skall läsa ifrån (kräver dock att du alltid har en öppen koppling mot databasen).

- M

Du fick det hela rätt förutom på en punkt ;)

Gladh skrev:

Får se om jag har förstått bättre nu :).

- Du har en services som skall skriva in massor med data till en annan databas. Vem kallar på denna services? Var får den sin data ifrån? Är det kritisk data? Vad händer om denna services går ner? Är det denna data som du vill att din .NET applikation skall få reda på?

- M

Detta är lite av ett problem, eftersom vi inte kan styra vb programmet till att notifiera den servicen måste vi göra ett event som läser en gång var 100/200ms detta går inte lösa på något sätt annat än att göra en egen variant av vb programmet och det skulle ta väldigt lång tid vi inte har.

För att göra det hela lite knepigare ändå så kommer vb programmet få sina inställningar via vår winform via databasen eftersom man vill kunna gå tillbaka och kontrollera vilka inställningar som har använts vid tidigare körning och för att kunna återanvända dessa i framtiden. När användaren av winformen ändrar inställningar ska dessa sparas i databasen och då ska vi notifiera vb programmet att det har skett ändringar.

Jag vill helst inte ha något onödigt i själva winformen eftersom den ska rita en del i realtid baserat på information från databasen.

Det är just ritandet som gjorde att jag funderade på WPF först men vi har inte bestämt något än.

CatZ skrev:

Detta är lite av ett problem, eftersom vi inte kan styra vb programmet till att notifiera den servicen måste vi göra ett event som läser en gång var 100/200ms detta går inte lösa på något sätt annat än att göra en egen variant av vb programmet och det skulle ta väldigt lång tid vi inte har.

Får se här nu, så den "dataservices" som skall skriva till databasen får inte sin data, utan den måste hämta den från vbapplikationen, och för att det skall fungera så måste ni polla mot vbapplikationen eftersom vbapplikationen inte kan anropa er services?

Vad gör vbapplikationen för avancerade saker, för det låter som ni är helt beroende av denna och kan inte ändra något i den. Vilket får er att bygga "dåliga hacks" för att komma runt problemet. Är interfacet mot vbapplikationen helt färdigt eller är det någon som måste in och ändra i vbapplikationen för att ni skall kunna kalla på den från er services. Om det ny är så att man måste in och ändra i vbapplikationen så kanske det är bättre och skippa det interface mot er services och låta vbapplikatione helt enkelt spara ner information i en XML-fil på servern någonstans och sedan låter ni er services ha en läsare på det biblioteket som känner av när något har ändrats i det biblioteket och så fall så läser man upp XML-filen och processar datorn. På det sättet så slipper du pollingen och får ett eventbaserat system istället. Eller ännu bättre att vbapplikationen skriver ner sina data till en kö istället som er services läser ifrån, då blir det dessutom transaktionssäkert och inga meddelande kommer att försvinna.

CatZ skrev:

Det är just ritandet som gjorde att jag funderade på WPF först men vi har inte bestämt något än.

Skall ni rita något på skärmen i realtid så är GDI+ helt värdelöst, riktigt långsamt, då föreslår jag istället att ni tittar på DirectDraw, som är betydligt snabbare. WPF är väl okej, jag har dock ingen anning hur det är prestandamässigt men misstänker att det är betydligt långsammare än DirectX.

- M

Gladh skrev:

Får se här nu, så den "dataservices" som skall skriva till databasen får inte sin data, utan den måste hämta den från vbapplikationen, och för att det skall fungera så måste ni polla mot vbapplikationen eftersom vbapplikationen inte kan anropa er services?

Vad gör vbapplikationen för avancerade saker, för det låter som ni är helt beroende av denna och kan inte ändra något i den. Vilket får er att bygga "dåliga hacks" för att komma runt problemet. Är interfacet mot vbapplikationen helt färdigt eller är det någon som måste in och ändra i vbapplikationen för att ni skall kunna kalla på den från er services. Om det ny är så att man måste in och ändra i vbapplikationen så kanske det är bättre och skippa det interface mot er services och låta vbapplikatione helt enkelt spara ner information i en XML-fil på servern någonstans och sedan låter ni er services ha en läsare på det biblioteket som känner av när något har ändrats i det biblioteket och så fall så läser man upp XML-filen och processar datorn. På det sättet så slipper du pollingen och får ett eventbaserat system istället. Eller ännu bättre att vbapplikationen skriver ner sina data till en kö istället som er services läser ifrån, då blir det dessutom transaktionssäkert och inga meddelande kommer att försvinna.

Det är många kockar till den här soppan... Tyvärr kan vi inte styra detta. Vi fångar upp informationen och skriver den till databasen, vb-applikatione gör inte annat än att registrera skickat och mottaget, det är upp till oss att göra någonting med den trafiken och det är här diverse olika service kommer in. VB-applikationen används av maskiner som utför olika jobb. Vi skickar order till vb-programmet som ser till att maskinerna utför det vi vill samt får tillbaka resultatet av det maskinerna utfört.

Vi skulle helt klart kunna använda oss av Xml-filer eftersom vi själva styr hur datan lagras. Den mesta data är efter utfört jobb mest för statistik och historik

Gladh skrev:

Skall ni rita något på skärmen i realtid så är GDI+ helt värdelöst, riktigt långsamt, då föreslår jag istället att ni tittar på DirectDraw, som är betydligt snabbare. WPF är väl okej, jag har dock ingen anning hur det är prestandamässigt men misstänker att det är betydligt långsammare än DirectX.

Du har nog rätt. Jag tror det sitter rätt värdelösa grafikkort i våra tunna klienter som utför ritandet, kanske finns det mycket prestanda att vinna med directx då?

catz skrev:

Du har nog rätt. Jag tror det sitter rätt värdelösa grafikkort i våra tunna klienter som utför ritandet, kanske finns det mycket prestanda att vinna med directx då?

Det vill ju till att grafikkorten stödjer er DirectX version också så fall. Så det är ju inte läge att bygga något i DirectX10, utan snarer i någon äldre version så fall...

- M