[ASP-SQL] Rare tekens na insert/update in MSSQL - Softwareontwikkeling

dinsdag 18 juli 2006 11:23

Acties:

Verwijderd

Topicstarter

He lijsters,
Ik heb jullie inzicht even nodig..

Situatie:

CMS beheerpagina haalt record uit mssql database. De betreffende invoervelden laten juiste data zien. Na het opslaan veranderd de é in een i en de ë in een k ??? In de database is het ook als zodanig opgeslagen. Verander ik de data weer in de de database dan laat de beheerpagina het weer goed zien. Wat gaat er fout tijdens het opslaan?

De pagina heeft de volgende structuur:

code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

De database heeft een nederlandse taal instelling.
De update qeury (in verkorte vorm) is als volgt:

code:

Sprojectnaam = Stringchecker(Uploader.Form("projectnaam"))

DIM SQLUpdateProject,RecordUpdateProject
SQLUpdateProject = "UPDATE project SET "
SQLUpdateProject = SQLUpdateProject & "projectnaam = '"&Sprojectnaam&"' "
SQLUpdateProject = SQLUpdateProject & "WHERE id_project = '"&SidGekozenProject&"'"
Set RecordUpdateProject = connectie.Execute(SQLUpdateProject)

De stringchecker functie:

code:

Function Stringchecker(Vstringcheck)
If IsBlank(Vstringcheck) = FALSE THEN
    Dim Vstring_array(5,2)
    Dim Vaantal_in_array
    Dim i 
    Vstring_array (0,0) = "'"
    Vstring_array (0,1) = "&#8217;"

    Vstring_array (1,0) = "&#8216;"
    Vstring_array (1,1) = "&#8216;"
    
    Vstring_array (2,0) = "&#8217;"
    Vstring_array (2,1) = "&#8217;"
    
    Vstring_array (3,0) = "&#8211;"
    Vstring_array (3,1) = "&#8211;"

    Vstring_array (4,0) = "&#8220;"
    Vstring_array (4,1) = "&#8220;"

    Vstring_array (5,0) = "&#8221;"
    Vstring_array (5,1) = "&#8221;"

    
Vaantal_in_array = Ubound(Vstring_array)

    WHILE i < Vaantal_in_array
        Vstringcheck = Replace(Vstringcheck,Vstring_array(i,0),Vstring_array(i,1))
    i = i + 1
    WEND
    Stringchecker = Vstringcheck
ELSE
Stringchecker = Vstringcheck
END IF
End Function

Het zal toch niet zo zijn dat ik alle rare karakters moet definieren in deze functie? dat is bijna onbegonnen werk. Kan er op de database een rare karakterset geladen worden?

dinsdag 18 juli 2006 11:30

Acties:

TeeDee

CQB 241

Wat wil je precies met die StringChecker doen? Kan je daar gewoon niet beter Server.HtmlEncode voor
gebruiken?

Sterker nog, ik vermoed dat je de Stringchecker als een Escape-achtig iets gebruik om je SQL querys niet te laten breken op het inserten van een quote ('). Dat kan je makkelijk fixen door het volgende te doen:

ASP:

1
2
3

dim mijnVar
//dus vervang 1 quote met 2 quotes
mijnVar = Replace(JeAnderVariableMetEenQuoteErin, "'", "''")

En dan je database in.

Of ik moet er helemaal naast zitten.

Je zou ook nog kunnen kijken naar de encodings in je database, maar als dit soort dingen fout gaan, dan is er iets danig mis met de config van je MS-SQL database.

[ Voor 6% gewijzigd door TeeDee op 18-07-2006 11:38 ]

Heart..pumps blood.Has nothing to do with emotion! Bored

dinsdag 18 juli 2006 11:40

Acties:

PolarBear

Geparametiseerde queries is het toverwoord hier. Of te wel http://www.google.com/sea...d=opera&ie=utf-8&oe=utf-8

Gewoon doen!

dinsdag 18 juli 2006 11:40

Acties:

whoami

Maak gebruik van parametrized queries, ipv je queries dmv string concatenation op te bouwen en je parameter waardes er aan te plakken.

https://fgheysels.github.io/

dinsdag 18 juli 2006 11:51

Acties:

Verwijderd

Topicstarter

Oke, parametrized queries! Moet ik dan ook de overstap naar .net maken? Nu is alles geprogrammeerd in asp.

dinsdag 18 juli 2006 11:53

Acties:

P_de_B

Nee hoor :)

Oops! Google Chrome could not find www.rijks%20museum.nl

dinsdag 18 juli 2006 12:05

Acties:

Verwijderd

Topicstarter

P_de_B schreef op dinsdag 18 juli 2006 @ 11:53:
Nee hoor :)

Gaaf! Wel al veel gehoord over SQL injecties maar nog nooit van parametrized queries. Ga het direct uitzoeken. Bedankt voor deze wijze tip.

dinsdag 18 juli 2006 12:08

Acties:

wboevink

Als je dan toch met parameters gaat werken maak er dan een stored procedure van.
Maar goed ik denk niet dat het je probleem oplost.
Het heeft te maken met de instelling van je karakterset op de pagina en de instelling van het karakterset (collation) in je SQL Server (of op database niveau).
Zijn je databasevelden wel ntext of nchar of nvarchar?
Ik doe altijd alles met utf-8, zonder problemen.

[ Voor 67% gewijzigd door wboevink op 18-07-2006 12:11 ]

dinsdag 18 juli 2006 12:18

Acties:

Verwijderd

Topicstarter

wboevink schreef op dinsdag 18 juli 2006 @ 12:08:
Als je dan toch met parameters gaat werken maak er dan een stored procedure van.
Maar goed ik denk niet dat het je probleem oplost.
Het heeft te maken met de instelling van je karakterset op de pagina en de instelling van het karakterset (collation) in je SQL Server (of op database niveau).
Zijn je databasevelden wel ntext of nchar of nvarchar?
Ik doe altijd alles met utf-8, zonder problemen.

de database heeft latin1 als karakterset, de velden zijn varchar. Ik gebruik geen ntext, nchar of nvarchar omdat ik daar niet binnen kan zoeken. (tenminste mijn kennis zal niet toereikend zijn want ik heb alleen maar problemen gehad met nvelden brrr

dinsdag 18 juli 2006 12:18

Acties:

TeeDee

CQB 241

wboevink schreef op dinsdag 18 juli 2006 @ 12:08:
Als je dan toch met parameters gaat werken maak er dan een stored procedure van.

Waarom een Sproc?

Heart..pumps blood.Has nothing to do with emotion! Bored

dinsdag 18 juli 2006 12:27

Acties:

Verwijderd

Topicstarter

TeeDee schreef op dinsdag 18 juli 2006 @ 12:18:
[...]

Waarom een Sproc?

Lijkt me een discussie zonder einde. Denk dat dit per query kan verschillen. De select statements wellicht wel maar insert en update niet...

dinsdag 18 juli 2006 12:31

Acties:

kenneth

achter de duinen

Sowieso is het out of the blue roepen dat er dan maar een SP van gemaakt moet worden een beetje raar ... welk probleem heb ik gemist dat het moet oplossen?

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

dinsdag 18 juli 2006 12:51

Acties:

TeeDee

CQB 241

kenneth schreef op dinsdag 18 juli 2006 @ 12:31:
Sowieso is het out of the blue roepen dat er dan maar een SP van gemaakt moet worden een beetje raar ... welk probleem heb ik gemist dat het moet oplossen?

Dat bedoel ik.

Een dynamische opgebouwde geparametriseerde query is net zo performant als een sproc. Akkoord, er zullen altijd wel uitzonderingen zijn, maar die uitzonderingen zullen imo beide kanten op kunnen gaan.

Heart..pumps blood.Has nothing to do with emotion! Bored

dinsdag 18 juli 2006 13:05

Acties:

wboevink

Een Sproc is in dit geval inderdaad een kwestie van smaak, maar daar ging mijn bericht ook niet over.

Ik denk toch dat je er nvarchar van moet maken. In text en ntext velden kun je inderdaad niet zoeken (tenzij je een fulltext index maakt) maar in nvarchar en nchar velden kun je wel gewoon zoeken.

de ndatatypes zijn voor unicode en dat is wat je wilt.

[ Voor 9% gewijzigd door wboevink op 18-07-2006 13:07 ]

dinsdag 18 juli 2006 13:11

Acties:

wboevink

kenneth schreef op dinsdag 18 juli 2006 @ 12:31:
Sowieso is het out of the blue roepen dat er dan maar een SP van gemaakt moet worden een beetje raar ... welk probleem heb ik gemist dat het moet oplossen?

Zoals gezegd 'Maar goed ik denk niet dat het je probleem oplost.'
Ik bedoelde eigenlijk dat ik er een SP van zou maken, zo had je het ook kunnen lezen.
Genoeg woorden vuil gemaakt hieraan denk ik.

dinsdag 18 juli 2006 14:02

Acties:

whoami

wboevink schreef op dinsdag 18 juli 2006 @ 13:05:
Een Sproc is in dit geval inderdaad een kwestie van smaak, maar daar ging mijn bericht ook niet over.

Nou, in eerste instantie ging het daar wel over

, en het is idd een beetje raar om 'out of the blue' te zeggen dat je hier een SP moet gebruiken. SP's hebben voor- en nadelen, en in sommige gevallen gebruik je best een SP, in andere niet.
Echter, het topic gaat niet over SP's, dus laten we die discussie hier niet voeren, en verder on-topic gaan.

Ik denk toch dat je er nvarchar van moet maken. In text en ntext velden kun je inderdaad niet zoeken (tenzij je een fulltext index maakt) maar in nvarchar en nchar velden kun je wel gewoon zoeken.

de ndatatypes zijn voor unicode en dat is wat je wilt.

Het probleem dat de topicstarter heeft, vloeit idd voort uit een encoding probleem. Echter, ook een niet uni-code veld moet in staat zijn om characters als è, é, à, ë, e.d. op te slaan.

[ Voor 23% gewijzigd door whoami op 18-07-2006 14:04 ]

https://fgheysels.github.io/

Pagina: 1

Reageer