Jag skulle vilja ha ett råd vad gäller följande: Om det är mycket du ska göra så föreslår jag nog att du i triggern bara skriver till en loggtabell, och sedan låter du din beräkningsapplikation köra i bakgrunden och plocka loggningarna efterhand. Hej och tack för ditt svar. Det var just denna beräkningsapplikation vi undrade på. Ska man göra den som en exe-fil eller något ? Tidigare har nämligen Microsoft pratat mycket om com-objekt och vi undrade lite vad detta innebar och hur dessa componenter kunne kopplas till sql-server ? Ett com-objekt är bara en klass som implementerar vissa interface. Alla klasser skapade i VB6 är com-objekt. Kommer nog vara svårt att felsök. Men man kan skapa en klass och anrope en metod på den: Inte bara svårt att felsöka, det är även en typisk felkälla. :) Tack igen för alla svar. Vad säger du om Extended Stored Procedures. Det är det tillräckligt stabila? Skriver man en egen XP kan man ju se till att den blir stabil. (Undrar vad Murphy skulle säga om det...)Råd SQL; VB; TRIGGER
En trigger i SQL ska bevaka en tabell för insert, update och delete.
När detta sker skall en beräkningsapplikation köras igång och göra ett antal uppgifter som ska resultera i en insert, update eller delete i en tabell.
Beräkningsapplikationen kommer att få ganska mycket att göra.
Nu vill jag ha ett råd om vilken typ Beräkningsapplikationen ska vara, vill helst skriva komponenten i VB och inom vilket "skal" den ska kallas från triggern.
Tackar på förhandSv: Råd SQL; VB; TRIGGER
Sv: Råd SQL; VB; TRIGGER
Sv: Råd SQL; VB; TRIGGER
Sv: Råd SQL; VB; TRIGGER
OLE Automation Objects in Transact-SQL
http://msdn.microsoft.com/library/en-us/acdata/ac_8_qd_14_7bcc.aspSv: Råd SQL; VB; TRIGGER
Jag rekommenderar absolut inte att använda com-objekt inifrån SQL Server genom sp_OA-procedurerna. De har genom åren varit kända för massor med minnesläckor, och de har redan från början en ganska begränsad mängd minne att arbeta med.Sv: Råd SQL; VB; TRIGGER
Vi har varit inne på att använda com-objektet, men efter Christoffers svar känns ju inte det så lockande.
Har ni fler kloka råd att dela med er?
Nu lutar det åt att vi gör följande:
Vi låter en trigger skriva till en logg fil och gör beräkningsapplikationen som en standard exe VB6 (vi behöver ett användargränsnitt på beräkningsapplikationen, med start och stoppknappar och lite annat) som sedan bevakar loggfilen och gör beräkningarna och skriver tillbaka till sql servern.
Några kommentarer eller råd vad gäller detta?Sv: Råd SQL; VB; TRIGGER
Men det förutsätter att amn skriver dem i C/C++ eller Delphi.
http://msdn.microsoft.com/library/en-us/odssql/ods_6_con_01_22sz.aspSv: Råd SQL; VB; TRIGGER
Dock gäller även för dem att de har en begränsad mängd minne och jag tycker inte man ska använda dem mer än man behöver. Dessutom, anropa något sådant från en trigger som helst bara ska gå så snabbt som möjligt känns inte riktigt bra. Som sagt, det bästa som jag kan tänka mig, om situationen tillåter det, är att man loggar till en tabell, och sedan har man ett externt program som ligger och läser denna tabell lite då och då.
I Yukon däremot, där blir det nog annorlunda...