Tjenixen.. Ett fält i en tabell bör inte innehålla mer än ett värde, och ha mer än en innebörd. Därför bör du flytta dina sökord till en egen tabell med en koppling till huvudtabellen. Sen kan du använda följande fråga för att lösa ditt problem: Njae.. Har gjort såhär förut men då har jag ju loopat.. hmm.. Men det borde ju finnas nåt kommando som är liknande InString, *suck* Ööh? Jo, visst går det att lösa med en loop i ett komma-baserat fält. Men det är inte det bästa sättet att lösa det. Som sagt, ett fält i en databas bör inte (rättare sagt ska inte) innehålla mer än ett värde. Både prestanda- och hanteringsmässigt är det bättre att lägga det i en egen tabell. Håller med Christoffer. Men om du inte vill köra på det kan du använda flera kriterier i din fråga separerade med OR. Det har du ju IOFS rätt i.. Att jag inte tänkte på det.. Tänk på att du då kommer att få dubletter på de som överensstämmer med bägge kriterierna. Njae.. JAg ska ju ändå kolla så att inte den artikel jag läser kommer med så då kan jag ju lika gärna kolla så att det inte är några dubletter heller... Dubbletter... det har jag inte stött på tidigare. Testade att göra en liknande fråga i Access med flera kriterier där två av dessa matchar en och samma post och fält. Men jag får endast upp den en gång... Eller har jag fattat fel? Hmm. Det har du ju rätt i ju.. Du är inte dum du.. Det borde ju bli bara en för det.. hmm.. nej det är ju nog sant förresten. Det var på ren intuition jag tänkte det, men vid närmare eftertanke gör nog SQL Server så att den stannar efter att det första alternativet stämmer. Men men, fortfarande är det bättre att lägga sökorden i en egen tabell. Nu måste ju dessutom frågan skapas dynamiskt beroende på hur många alternativ man vill kolla med WHERE-klausuler. Jo men det är ju inte direkt svårt och det tar ju inte alls mycket på prestandan om man gämför med vad jag tänkte göra från början.. *ler* eeh, jo det gör ganska mycket skillnad på prestandan. OK, om man ändå bara hade tänkt skriva en enkel fråga i ett recordset och köra den, kanske inte så mycket skillnad. Men så bör man inte köra sina frågor, antingen ska man köra lagrade procedurer (genom commandobjektet) eller åtminstone köra parameteriserade frågor. Då kommer SQL Server (oftast) att utnyttja samma execution plan som förra gången frågan kördes, vilket gör att det går betydligt fortare.InStr i SQL fråga??
Har ett litet "problem"..
Jag har ett fält i en tabell i databasen som heter sokord..
Det är ett kommabaserat fält där man ska skriva in passande sökord till den artikel man är på tex "Erin, Brokovich, Julia".
Och ifrån dessa sökord ska man få fram andra relaterande artiklar typ..
Provade med Like
"Select * From SenasteNytt Where Rubrik Like '%%Erin, Brokovich, Julia%%'"
Men det gav ju bara resultat om Erin fanns med.. Inte om Julia fanns med..
Så det jag skulle behöva är typ InString i SQL frågan. som kollar på hela ord inte på bokstäver.
Man kan ju splitta upp det till en array och loopa frågan så många gånger som det finns sökord.. men det är ju inte så bra prestanda mässigt antar jag..
Svara snarast!!Sv: InStr i SQL fråga??
SELECT SN.*
FROM SenasteNytt AS SN
INNER JOIN Sokord AS SO
ON SN.Id = SO.SN_Id
WHERE SO.Rubrik IN ('Erin', 'Brokovich', 'Julia')Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
WHERE (Rubrik LIKE '%Erin%') OR (Rubrik LIKE '%Brokovich%') osv...Sv: InStr i SQL fråga??
(det gäller ju bara ca 1 till 2 sökord så jag tycker det är onödigt att lägga upp en egen tabell)Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
Sv: InStr i SQL fråga??
Iofs vet jag inte om frågan gällde sql server eller access, men jag tycker i vilket fall som helst att databasen bör normaliseras, inte så mycket för prestanda utan framförallt för hanteringsbarhet.