Pozdravljeni!
Uporabljam VS2005 z SQL 2000 Serverjem. Programiram pa v Asp.net z C#.
Imam sledeč problem. Vnos datuma v SQL bazo.
V texbox-u vnesem datum v fromatu dd.mm.llll. Ko hočem vnesti ta datum v bazo mi javi error, češ da ni pravi format.
koda:
string InsertCmd = "insert into table (veljavnost) values('" + textbox1.text + "')";
Probal sem tudi z textbox1.text.ToString("DD.MM.YYYY") <- tu pa seveda mi je javil napako
Kakšna je še drugačna rešitev?
Hvala Vam za odgovor.
lp
Matijaž
Avtor: matijaz, objavljeno na portalu SloDug.si (Arhiv)
pril - ponedeljek, 23. april 2007
Mene tudi - Markič je itak legenda Tako se začnejo dobre diskusije...lp, pl
spirit1 - ponedeljek, 23. april 2007
Miha, me prav zanima tvoja replika v tem primeru
pril - ponedeljek, 23. april 2007
MihaM: pril: Stored procedures can be individually secured within the database. A client can be granted permissions to execute a stored procedure without having any permissions on the underlying tables.Če imaš bazo namenjeno samo za web server, čemu dodaten security (auditing in ostalo je sploh bolje če je izključeno - lepo prišparaš na performancah)Se ti malo hecaš, a?nope... lp, pl
MihaM - ponedeljek, 23. april 2007
pril: Stored procedures can be individually secured within the database. A client can be granted permissions to execute a stored procedure without having any permissions on the underlying tables.Če imaš bazo namenjeno samo za web server, čemu dodaten security (auditing in ostalo je sploh bolje če je izključeno - lepo prišparaš na performancah)Se ti malo hecaš, a?
pril - ponedeljek, 23. april 2007
Ja, se strinjam - iis naj nima dbo pravic - to je pomebno! Že kar na začetku razvoja delaj z drugim userjem.Audit (pri meni) ni preveč zaželjen (potem imaš lahko še posebej performance tuning za sam audit :-) Pri meni načelno do baze dostopa dbadministrator/razvijalec in aplikacija - za to dvoje pa ne vem če je potreben audit - ampak, kot že rečeno: odvisno od zahtev. Sam razvoj (lepši debug in intellisense,..) mi je osebno bolj pri srcu za .net kodo kot za procedure (čeprav je sedaj isto, na 2005, lahko procedure delaš v .net kodi), compajl in deploj imam potem vedno narejen na en klik. Podaljšano bussines logiko raje ponujam z web servisi, se mi zdijo bolj univerzalni, lažje dostopni in tudi imam občutek da se da naredit več... no, več kot očitno je da stvar ni eksaktna, na koncu mogoče vse bolj kroji lastna filozofija in osebni pogled na stvar.Všeč so mi debate, kjer sodelujete ljudje, ki precej veste o stvari (se mi zdi da je to eden redkih takih forumov v slo) tako, da se vsi nekaj naučimo Lp vsem,Primož
petar.repac - ponedeljek, 23. april 2007
>Ja, saj - mogoče še moj komentar na tole - pa mi bo mogoče še kdo kaj povedal, da si obnovim znanje o bazah >> * Stored procedures generally result in improved performance because the database can optimize the data access plan used by the procedure and cache it for subsequent reuse.>>Pri navadnem insertu ni execution plana - vsaj jaz ga ne vidim takega, ki bi kaj koristil - paravzaprav ga baza pri več insertih sploh neha delat, (tako kot pri alter, nekaterih trigerjih ga niti ne naredi ipd). Prav tako velja za enostavne parametrizirane sql stavke, za katerega ne delaš ročnega execution plana - ko se prvič izvede se itak kompajliran sql stavek, skupaj z execution planom spravi v cache na bazi) - za ostalo naj se seveda nujno uporablja sproce.1. Baza sproc kompilira, torej si lahko določene zadeve pripravi vnaprej, npr. izvajalni plan. Tega drugače baza mora izračunati ko prvič dobi sql stavek (če delamo z parametri lahko ta plan potem kešira in uporabi večkrat).> * Stored procedures can be individually secured within the database. A client can be granted permissions to execute a stored procedure without having any permissions on the underlying tables.>>Če imaš bazo namenjeno samo za web server, čemu dodaten security (auditing in ostalo je sploh bolje če je izključeno - lepo prišparaš na performancah)2. Če sam razvijaš sistem mogoče imaš dober nadzor nad tem kateri so inserti nad bazo in kaj delajo. Pri večjih projektih pa mogoče oseba, ki razvija načrt baze ne razvija tudi srednjega/UI nivoja. Pogosto je zaželeno da se že na nivoju baze omejimo kaj naš design baze ponuja kot API navzven. Tako lahko implementiraš tudi določen del poslovne logike.3. Recimo da iz ASP.NET aplikacije dostopaš do baze preko dbo uporabnika. Če nekdo udre v IIS bo zlahka prišel tudi do baze in to z dbo pravicami. To pomeni da lahko prebere vse, dropa tabele, ali pa hujše, spreminja po volji. Vdor v bazo je precej hujša zadeva kot vdor v IIS.> * Stored procedures result in easier maintenance because it is generally easier to modify a stored procedure than it is to change a hard-coded SQL statement within a deployed component.>>Ko popravljaš funkcionalnosti moraš potem oboje popravljat - source in bazo, da bi prišel skozi samo z popravljanjem procedure pomeni da je funkcionalnost napačna pri vrsti podatka (pa še to ne po tipu) , kar je zelo redko - ali pa imam jaz poseben način programiranja :-) , torej moraš v večini primerov popravljati na dveh mestih namesto na enem>4. Če imaš SQL stavke napisane v stored procedurah in se ugotovi da ti niso optimalno napisani, ali pa v produkciji dodamo določene indekse na tabele in posledično postane SELECT neoptimalno napisan je dovolj popraviti samo sproc. Drugače moraš popraviti kodo, narediti build, deployati, ...5. Če sql stavke pišeš v sproc ti jih baza avtomatično preveri. V kodi lahko napišeš karkoli...> >> * Stored procedures add an extra level of abstraction from the underlying database schema. The client of the stored procedure is isolated from the implementation details of the stored procedure and from the underlying schema.>>Do kje gre ta logika? Načelno bi lahko tudi html output gradil kar s sproci, ne? Meni je bolj všeč filozofija, da se baza ukvarja s podatki, ostalo obdelavo naj prevzame komponenta (sploh če imaš 3-tear aplikacije, ta nivo abstrakcije prevzame bussines layer, html npr pa presentation layer, db pa data layer )6. Po mojem mnenju je bolje če baza ponuja definiran API srednjemu nivoju. Drugače je data access layer samo podaljšek baze. Ne zdi mi se dobro z stališča arhitekture.>> * Stored procedures can reduce network traffic, because SQL statements can be executed in batches rather than sending multiple requests from the client.>>Več web strani težko spraviš v batch :-) (pazi - če se da, seveda za vsako stran zahtevaš po največ en db query, in še to samo za podatke, ki jih potrebuješ, ne npr cele tabele, za ostalo pa naj se uporabi cache že na web serverju, to potem resnično zmanjša promet do baze, sploh če je remote.)>>Vedno večkrat in pri različnih tehnologijah, se mi zdi, da m$ forsira neko uporabo ne samo zato, da bi bilo tako v resnici bolje, temveč tudi zato, ker je potem (delno) onemogočena uporaba drugih konkurenčnih tehnologij v drugih okoljih/orodjih (očitni primeri: smart navigation, paging ipd... ma, cel kup je tega) Saj ne da bi imej kaj proti m$ - to je moje glavno okolje, vendar tudi čisto razumem da je treba živet in da živimo v profitabilnem okolju - to je tudi razlog, da je potrebno stvari vzeti z razmislekom.>>Bom rekel še (mislim da pečenkove besede): mogoče se pa tudi motim...>>lp, pl.7. Kar se tega tiče lahko povem da Oracle bolj poznam kot Sql Server in napisano velja tudi tam. Drugače se strinjam s tem da MS včasih kr forsira svoje produkte, tako da razvojna orodja preveč prilagodi svojim produktom/filozofiji.LP, Petar
spirit1 - ponedeljek, 23. april 2007
naceloma se strinjam s tem kar si rekel razen:> Če imaš bazo namenjeno samo za web server, čemu dodaten security (auditing in ostalo je sploh bolje če je izključeno - lepo prišparaš na performancah)to je res, vendar takoj ko imas nek logon nekje v aplikaciji je auditing potreben. da ne omenjam da je recimo v ameriki zakon o auditingu, ki ga zahteva in se bo pocasi znasel tudi pri nas.> Ko popravljaš funkcionalnosti moraš potem oboje popravljat - source in bazo, da bi prišel skozi samo z popravljanjem procedure pomeni da je funkcionalnost napačna pri vrsti podatka...tale del si narobe razlagas. Tukaj je misljeno ce se recimo spremeni biznis zahteva vrnnjeni resultset pa ostane isti. je veliko lazje popravit sproc kot pa znova skompajlat in deployat kodo.Stored procedure so dobre tudi kot se en del Business Layer-ja. Nekatere stvari je pac bolje, da jih opravlja server nekatere pa client. ne pravim pa da je treba zdej vse tlacit v sproce. no MS forsira best practice za njegov izdelek kar je tudi prav.seveda je treba poudarit, da so za simpl stvari kot so navadni web page-i, ki samo prikazujejo stvari in ne zahtevajo ne vem kake hude biznis logike stored procedure overkill, gledano cisto iz hitrosti razvoja.vendar z vsemi ze obstojecimi CRUD generatorji je tudi ta argument malce slab. in pa nikoli ne ves kdaj bo aplikacija zrastla v nekaj vec. bolje biti pripravljen.
pril - ponedeljek, 23. april 2007
Ja, saj - mogoče še moj komentar na tole - pa mi bo mogoče še kdo kaj povedal, da si obnovim znanje o bazah Stored procedures generally result in improved performance because the database can optimize the data access plan used by the procedure and cache it for subsequent reuse.Pri navadnem insertu ni execution plana - vsaj jaz ga ne vidim takega, ki bi kaj koristil - paravzaprav ga baza pri več insertih sploh neha delat, (tako kot pri alter, nekaterih trigerjih ga niti ne naredi ipd). Prav tako velja za enostavne parametrizirane sql stavke, za katerega ne delaš ročnega execution plana - ko se prvič izvede se itak kompajliran sql stavek, skupaj z execution planom spravi v cache na bazi) - za ostalo naj se seveda nujno uporablja sproce.Stored procedures can be individually secured within the database. A client can be granted permissions to execute a stored procedure without having any permissions on the underlying tables.Če imaš bazo namenjeno samo za web server, čemu dodaten security (auditing in ostalo je sploh bolje če je izključeno - lepo prišparaš na performancah)Stored procedures result in easier maintenance because it is generally easier to modify a stored procedure than it is to change a hard-coded SQL statement within a deployed component.Ko popravljaš funkcionalnosti moraš potem oboje popravljat - source in bazo, da bi prišel skozi samo z popravljanjem procedure pomeni da je funkcionalnost napačna pri vrsti podatka (pa še to ne po tipu) , kar je zelo redko - ali pa imam jaz poseben način programiranja :-) , torej moraš v večini primerov popravljati na dveh mestih namesto na enemStored procedures add an extra level of abstraction from the underlying database schema. The client of the stored procedure is isolated from the implementation details of the stored procedure and from the underlying schema.Do kje gre ta logika? Načelno bi lahko tudi html output gradil kar s sproci, ne? Meni je bolj všeč filozofija, da se baza ukvarja s podatki, ostalo obdelavo naj prevzame komponenta (sploh če imaš 3-tear aplikacije, ta nivo abstrakcije prevzame bussines layer, html npr pa presentation layer, db pa data layer )Stored procedures can reduce network traffic, because SQL statements can be executed in batches rather than sending multiple requests from the client.Več web strani težko spraviš v batch :-) (pazi - če se da, seveda za vsako stran zahtevaš po največ en db query, in še to samo za podatke, ki jih potrebuješ, ne npr cele tabele, za ostalo pa naj se uporabi cache že na web serverju, to potem resnično zmanjša promet do baze, sploh če je remote.)Vedno večkrat in pri različnih tehnologijah, se mi zdi, da m$ forsira neko uporabo ne samo zato, da bi bilo tako v resnici bolje, temveč tudi zato, ker je potem (delno) onemogočena uporaba drugih konkurenčnih tehnologij v drugih okoljih/orodjih (očitni primeri: smart navigation, paging ipd... ma, cel kup je tega) Saj ne da bi imej kaj proti m$ - to je moje glavno okolje, vendar tudi čisto razumem da je treba živet in da živimo v profitabilnem okolju - to je tudi razlog, da je potrebno stvari vzeti z razmislekom. Bom rekel še (mislim da pečenkove besede): mogoče se pa tudi motim...lp, pl.
petar.repac - ponedeljek, 23. april 2007
Iz .NET Data Access Architecture Guide:You should use stored procedures instead of embedded SQL statements for a number of reasons: Stored procedures generally result in improved performance because the database can optimize the data access plan used by the procedure and cache it for subsequent reuse.Stored procedures can be individually secured within the database. A client can be granted permissions to execute a stored procedure without having any permissions on the underlying tables.Stored procedures result in easier maintenance because it is generally easier to modify a stored procedure than it is to change a hard-coded SQL statement within a deployed component.Stored procedures add an extra level of abstraction from the underlying database schema. The client of the stored procedure is isolated from the implementation details of the stored procedure and from the underlying schema.Stored procedures can reduce network traffic, because SQL statements can be executed in batches rather than sending multiple requests from the client.Dodal bi še to: vedno, vedno, vedno dostopaj do baze preko parametrov (tudi če dinamično konstruiraš SQL stavek se dajo programsko manipulirati tudi parametri).Vsaj dva razloga sta:1. varnost (če uporabljaš parametre se zaščitiš proti SQL injection-u) in2. performance (če uporabljaš parametre dovoliš bazi da uporabi že izračunan execution plan, če uporabljaš dostop preko parametrov se SQL stavki pogosto razlikujejo samo v vrednosti parametrov sami stavki so identični) lp, P.
pril - ponedeljek, 23. april 2007
Meni sproci niso všeč, ker moram potem na dveh mestih popravljat ko nekaj spremenim.. pa se ne bi čisto strinjal da so vedno potrebni - pri običajnem insert stavku se mi zdi, da procedura res ni potrebna (tudi za auditing - če je to web server in ne za splošne namene je to sam cokla, itak je sam en user) Tole ni mišljeno kot kritika, bolj kot predlog in kot je že rečeno - mnenja so različna, mogoče pa ne poznam zadeve tako dobro kot sogovorniki...Hehehe, tole sem pa že pozabil kako zgledajo tile parametri - to pa priporočam tudi tebi (vsaj pri meni se je obneslo): narediš si objekte za dostop do baze in izvajanje sql stavkov, ki znajo sami sestavit in sparametrizirat sql stavke (jest sem se še malo bolj pomatral pa se še testirajo najbolj optimalni načini za update/insert/delete metode, delajo enako na različnih bazah, oracle, mssql, mysql, access,. in druge metode) pa jih potem sploh ne uporabljaš več: vse kar te zanima je da daš notri podatek, al pa da ga dobiš ven, vse ostalo ti postane odveč - razvoj pa je bistveno hitrejši (ali je to transakcija, sql command, fill dataset ali reader, incalizacija ali pa karkoli - naj se stvari same zadaj poštimajo). Čez leto ali dve potem pozabiš kako je to sploh treba uporabljat lp, pl
AndrejT - ponedeljek, 23. april 2007
Sproci so lahko odveč le v primeru, da se ti jih ne da pisat ali pa nimaš dovolj znanja zanje, poleg je še njih vzdrževanje. Ne glede na to, ali uporabiš sproce ali sql stavke, so parametri the way to go. Zgornji stavek bi torej lahko izgledal kot:string InsertCmd = "insert into table (veljavnost) values(@veljavnost)";Nekje spodaj, preden zadevo izvršiš (kakorkoli že), pa bi se znašlo nekaj temu podobnega:insertCommand.Parameters.AddWithValue("@veljavnost", DateTime.Parse(textBox1.Text));... pri čemer je insertCommand tipa SqlCommand. Zraven paziš, da je datum v textBox1 res v pravi obliki (svetujem uporabo DateTime.TryParse namesto metode zgoraj, oz. neko podobno vrsto validacije, mogoče že z ustreznim validacijskim kontrolnikom).Seveda lahko stvari zapelješ čisto drugam, če uporabljaš druge mehanizme za delo z bazo (binding, DataSeti, itd).
spirit1 - ponedeljek, 23. april 2007
no prav naj mu bo osebno nikoli ne uporabljam sintakse insert into .. values... mi je neljuba vedno uporabljam insert into ... select...pri obeh pa lahko uporabis parameter.
pril - nedelja, 22. april 2007
ja, seveda, sproc je seveda koristna zadeva, včasih pa povsem odveč, odvisno od primera do primera.Jasno, da datetime nima veze z kulturo sql serverja, vendar če ga daje v string za insert v obliki stringa naj bo v kulturi baze, če ne ne bo delovalo.. kot je napisal.Se strinjam, najbolj simpl je parameter, jasno, nič onegavljenja lp, pl
spirit1 - nedelja, 22. april 2007
to je cel point parametrov. da ti ni treba delat datetime.ToString()ker ze imas datetime objekt in ga das naprej datetime objektu.se znebis celotne odisejade z stringi in datetime-i. tudi za insert je sproc dober. recimo auditing je najbolje da se implementira v sprocu in ne v trigerjih. locale od serverja je defaultno nastavljen na locale od operacijskega sistema na katerega instaliras.in pa nima nobene veze z date time formatom. v bazi so datetime objekti shranjeni kot 2 int-a.
pril - nedelja, 22. april 2007
No, za insert je stored procedura tako, tako - brez smisla :-) Razen če je kakšen zelo, zelo zapleten insert - v obliki insert-values pa res ni potrebe, nima baza kaj za v cache dat....Imaš kar celo kopico možnosti - varnost tukaj verjetno ni problem, če daješ direktno iz datumskega polja (ne pa direktno iz weba - pazi!) - to lahko narediš kar za konvercijo v datetime.ToString("d") - z kulturo ki jo podpira baza (pazi, sql server je običajno naštelan na ameriško kultur:-lcid=1033 - to bi bilo potem v obliki MM/DD/YY - vedno pa vedno dela v univerzalni obliki, vsaj kolikor se spomnim "YYYY-MM-DD HH:mm:SS") tip, potem pa tega v string, najbolj enostavno če daš v parameter. Lahko daš tudi v dataset potem pa narediš update (za kanček počasneje, ampak pri update-u podpira "optimistic" preverjanje, kar ni tak napačno). Hja, ne gradit stavkov v kodi je lahko rečeno samo za ponavljajoče querije, ti pa so itak v cache-u baze, tudi če jih sproti gradiš, če se le parametri uporabljajo... no, po želji... za kakšne scane tabel ipd pa jasno, samo stored procedura. Če rabiš objekte (žal brez source) za enostavnejši dostop do baze, updejt ipd ti lahko dam link na svoje komponente - jasno, ker jih sam uporabljam so mi to najbolj simpl objekti na svetu :-)lp, pl
spirit1 - nedelja, 22. april 2007
ce še nisi pa še bos kako dostopam do baze?ali preko dataseta ali pa kar z datareaderjem. cisto odvisno...drugace pa uporabljam vedno stored procedure ce se le da.nikoli ne gradim stavkov v kodi.ce pa jih ze moram (razni searchi) pa potem vedno uporabljam parametre.
matijaz - nedelja, 22. april 2007
Hvala ti za odgovor.Pogledal sem stran, ki si jo predlagal, vendar me pa zanima kako pa ti dostopaš v bazo, kr preko DataSet-a? No ua enkrat še nisem uvidel, bom pa vseeno častil pir pri naslednjem srečanju :)
spirit1 - četrtek, 12. oktober 2006
Tvoj nacin insertiranja je konceptualno napacen.To sem enostavno moral povedati :))ok zdej pa k resitvi.Za dostop do baze uporabljaj stored procedure in ne sql stavkov zgrajenih v kodi.ce jih gradis v kodi kot ti sedaj in to das na produkcijo, ti za 2 uri dobim ven vse podatke pa se bazo ti dropnem. tako da ne delaj tega.V google napisi SQL injection attack pa bos videl.ce ze moras obvezno graditi sql stavke v kodi uporabljaj paramtere.preberi si tole:http://weblogs.sqlteam.com/jeffs/archive/2006/07/21/10728.aspxKo uvidis svoja napacna pota mi lahko castis en pir na naslednjem srecanju :))no zdaj pa k tvojem problemu:ne dela ti iz preprostega razloga ker je tvoj sql server nastiman na mdy format in ne dmykot si ga zelis ti. to nastavitev spremenis z set dateformat dmy vedno ko delas z datumi jih poslji v bazo v formatu yyyy-mm-dd say je to univerzalen ISO standard.ker pa jih itak mas v datetime objektu itak nimas problemov z castanjem in lahko samo reces parameter = MyDateValue