webForumDet fria alternativet

SQL syntax

6 svar · 245 visningar · startad av Roland

RolandMedlem sedan mars 200139 inlägg
#1

Någon som vet var man (på nätet) kan hitta dokumentation till syntax för SQL med den dialekt som access och MS SQL-server använder ?

------------------
Tänkte inte på de'

LarsGMedlem sedan dec. 200012 465 inlägg
#2

SQL server http://msdn.microsoft.com/library/default.asp?URL=/library/psdk/sql/ts_tsqlcon_6lyk.htm

Det finns en table of contents till vänster där man kan välja olika avsnitt.

Access
http://msdn.microsoft.com/library/default.asp?URL=/library/techart/acintsql.htm

Det är ju så att SQL server och Access inte pratar samma SQL. Man kan inte heller säga att Jet SQL är en delmängd av det som finns i SQL server.

Dom har i och för sig en ganska stor del som är gemensam och sen så finns det väldigt mycket som finns enbart i SQL server

------------------
essentitia preter non sans multiplicandum

RolandMedlem sedan mars 200139 inlägg
#3

Tackar för tippset. Vad är skillnaderna i stora drag mellan SQL-server och aaccess ? Då med avseende på vanliga select, insert, update och delete. Jag tänker då ej på alla möjligheter för admnistration av upplägg av tabeller mm utan ren lösning/skrivning vilken är normal från applikationer. Givetvis måste databasen vara väl normaliserad vilket underlättar hantering från programmen.

------------------
Tänkte inte på de'

LarsGMedlem sedan dec. 200012 465 inlägg
#4

Om man håller sig till vanliga update/select så är det mesta gemensamt. En sak som som skiljer sig t.ex. är datum. Access använder # och sql server använder ' för att avgränsa datumvärden. De funktioner som finns för datum skiljer sig också lite. T.ex. getdate() dagens datum i SQL server och now() i Access.

Ett annat exempel är caseexpression som finns i SQL server, det är ett sätt att mappa värden. Denna funktion motsvaras av IIF funktionen i Access.

Det skiljer sig också i fråga om datatyper. I det fallet är det mest fråga om olika namn på samma sak. T.ex. så använder sig Access för memo för en blob medans SQL server har begreppet text.

De stora skillnaderna, med avseende på DML, är dock stored procedures och trigger där det i Access inte alls finns samma programmeringsmässiga möjligheter som i SQL server.

EOD.

------------------
essentitia preter non sans multiplicandum

RolandMedlem sedan mars 200139 inlägg
#5

För att ytterligare fördjupa mig, nu när Lars är "på tråden" så har jag nu enligt tips på detta forum börjat testa med att skriva/uppdatera/radera access direkt via SQL-satser mot tidigare gamla hederliga infogande direkt i RS. Är det någon direkt skillnad i prestanda att göra så eller är detta något som bara duger för mindre uppdateringar. Av erfarenhet är relationsdatabaser lite sega att uppdatera men har upplevt att tex access är relativt effektiv om man använder "gamla metoden" mot RS. Hur väljer man, är öppen för tips, samt går denna metod mt RS även i SQL-server ?

------------------
Tänkte inte på de'

LarsGMedlem sedan dec. 200012 465 inlägg
#6

Jo, det är effektivare att använda SQL direkt jämfört med recordset. Jag skulle inte påstå att det är att väldigt stora skillnader, utan det man kan vinna på är att man definerar index så att de passar dom frågor man ställer. Skillnaden i svarstid för att söka via ett index jämfört med en sekventiell sökning blir väldigt stora om man har hyfsat stora datamängder.

Tillägg: Det sägs ofta att man löser alla prestandaproblem genom att använda stored procedures. De fall därman tjänar på att använda stored procedures är de fall man skall behandla mycket data om det kan göras i proceduren utan att man behöver skicka en massa data över nätet. Det är också födelaktigt om man har flera operationer som behöver utföras som en transaktion om man då kan baka ihop dessa till ett anrop. Alltså den största vinsten med stored procedures är att slippa en massa kommunikation över nätet.

------------------
essentitia preter non sans multiplicandum

[Redigerat av LarsG den 06 apr 2001]

RolandMedlem sedan mars 200139 inlägg
#7

Tackar för tippsen. Skall testa och se hur svarstider blir med ren SQL.

------------------
Tänkte inte på de'

Genererad på 376 ms · cache AV · v20260730165559-full.f96bc7eb