Bedste løsning ved forskellige databaser ?

Er databasesystemet det samme, fx MSSql, kan du skifte connectionstring ud i web.config.
Er det forskellige databasessystemer, MySql / MSSql / etc, kan du lave forskellige moduler/klasser.

Det var også planen med forskellige dataklasser MsSqlData.vb, MySqlData.vb, AccessData.vb osv. men jeg skal have en smart måde hvorpå jeg ikke skal gøre andet end at skifte et sted f.eks i web.config og dette skal jeg bruge et eksempel på.

/Websam

connection string i konfigurations fil
ingen brug af database specifikke klasser i koden (det kan godt lade sig goere)
standard SQL

http://www.eksperten.dk/artikler/694

afsnittet "Database connections"

Mig bekendt er der da forskel på OleDbConnection, OleDbCommand vs. SqlConnection, SqlCommand det komemr jeg vel ikke udenom at skulle gøre systemet opmærksom på nogle steder ?

/Websam

Nu formoder jeg at du har skrevet alt dette som Windows application ?

Jeg har så lige måtte oversætte lidt da det {} ikke er min stærke side, men ser det her rigtigt ud ?

Imports System
Imports System.Data
Imports System.Data.Common
Imports System.Data.SqlClient
Imports System.Data.OleDb
Imports System.Data.Odbc

Public Class MultiDb2
  Private Shared Sub test(ByVal provider As String, ByVal constr As String)
    Dim dbf As DbProviderFactory = DbProviderFactories.GetFactory(provider)
    Dim con As IDbConnection = dbf.CreateConnection
    con.ConnectionString = constr
    con.Open
    Dim cmd As IDbCommand = con.CreateCommand
    cmd.CommandText = "SELECT * FROM T1"
    Dim rdr As IDataReader = cmd.ExecuteReader
    While rdr.Read
      Dim f1 As Integer = CType(rdr(0), Integer)
      Dim f2 As String = CType(rdr(1), String)
      Console.WriteLine(f1 + " " + f2)
    End While
    con.Close
  End Sub

  Public Shared Sub New(ByVal args As String())
    test("System.Data.OleDb", "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Databases\MSAccess\Test.mdb")
    test("System.Data.SqlClient", "server=ARNEPC3;Integrated Security=SSPI;database=Test")
  End Sub
End Class

/Websam

"standard SQL" er en begrænsning, der nok kan lade sig gøre i legetøjseksempler, men som ikke bør være begrænsningen i rigtige applikationer i det virkelige liv. Syn's jeg.

det er en console app, men det relevante nemlig brugen af databse klasser
kan bruges i console / windows GUI / web / web service / windows service

det ser rigtigt ud

erik>

det er jeg ikke enig i

alle af foelgende 3 ses faktisk i det virkelige liv:
1)  heftig brug af databse specifikke features og derfor kun understoettelse for en database
2)  ingen SQL i koden men genererer automatisk SQL - og det vil ofte
    vaere database specifik SQL til den specifikke database
3)  ren standard SQL

Man skal naturligvis taenke sig lidt om, men mange applikationer kan faktisk
noejes med ret simple CRUD operationer, hvis man er bevidst om det. Nogle gange
skal man saa flytte noget logik fra SQL til applikationen, men
ikke noedvendigvis et problem.

Hvor meget af følgende betegnes som standard Sql :

SQL Select
SQL Where
SQL Insert
SQL Update
SQL Delete
SQL Order By
SQL AND & OR
SQL In
SQL Between
SQL Aliases
SQL Join
SQL Union
SQL Create
SQL Drop
SQL Alter
SQL Functions
SQL Group By
SQL Select Into

/Websam

For øvrigt så kan der vel ikke bruge parametre når man benytter den metode jeg postede ovenfor ?

/Websam

stort set det hele

undtagelserne er:

CREATE i sig selv er standard, men der er ofte database specifikke ting i dem,
men det man ofte goer er at man ikke putter CREATE statements i sin applikation
men vedlaegger et SQL scripts til administratoren og hvis det ikke kan laves
database uafhaengigt saa laver man et script per database (men hvor ens app
stadigvaek er standard SQL)

functions (jeg antager at du mener diverse streng / matematik / tids manipulerings
funktioner, MIN/MAX/AVG/COUNT er standard, user defined functions a la
stored procedures er absolut ikke standard) skal man undgaa - de er naesten
altid forskellige mellem databaser - hvis man ikke kan undgaa kan man evt.
vaelge funktions navne udfra database type (der er en del funktioner
som alle database har men som bare hedder noget forskelligt)

[jeg kan ikke husk eom SELECT INTO er standard]

der er ogsaa I'er til parameters, men du har ikke fuld type check

Ja men så har jeg ingen problemer med at benytte det og sikke en tids besparende faktor jeg lige fik hentet der ;o)

Det jeg var ude efter at vide var nemmelig det med min/max/avg/count/datepart osv. som er dem jeg bruger en del dertil kommer så diverse joins/and-or osv. så hvis ikke det er noget problem har jeg det heller ikke da oprettelse af sql database foregår som du skriver med sql-scripts access understøtter det godt nok ikke men når jeg en gang har lavet én skal jeg jo blot kopiere den.

/Websam

Ville jeg så skulle bruge beskyttelse mod sql injections istedet ?

/Websam

datepart er en af de farlige funktioner

----

man kan nemt lave en loader til Access som udfoerer multiple SQL statements

nej I'er til parameters burde vaere OK

Ok, den kan så også undværes, da jeg kan behandle dato'er inden de bruges i sql.

Er det her så mådenjeg kalder parametre på.

Dim param As IDbDataParameter

hvis det viser sig at du har 2 SQL saetninger som bare er svaere at faa standard
saa er du lidt kreativ og gemmer noget SQL string format i konfig

eller kryber til korset og laver lidt forskellig kode

jeg er ikke fanatiker med hensyn til saadan noget - men langt det meste SQL
kan laves standard hvis man taenker paa det

og jeg graeder indvendigt naar jeg ser [] eller `` omkring navne, funktioner
brugt totalt uhaemmet etc.

der er et eksempler paa brug i docs mener jeg

Nu benytter jeg mig jo mest af Insert, Update, Delete og Select. De 3 første bør ikke på noget som helst tidspunkt volde problemer. Select kan der kommespøgsmål til, men for det meste trækker jeg jo blot en bunke data ud, smidderdet i cache og derfra bruger de muligheder der er.

Og du kan være helt rolig jeg bruger hverken [] el '' i mine sql'er den alder er jeg over *GGG*

/Websam

Jeg fik læst lidt mere på det og det eneste jeg kan komme frem til er følgende måde at oprette en parameter :

Dim pName As DbParameter = objComm.CreateParameter()
pName.ParameterName = "Name"
pName.DbType = DbType.String
pName.Size = 50
objComm.Parameters.Add(pName)

Men det virker godt nok noget vildt at der skal så meget til for så lidt ?

/Websam

fordi den ikke har en god Add ?

men hvad saa - koden er jo letlaeselig - antal linier i seig selv betyder ikke saa meget

hvis du gaar op i det kan du jo kigge paa mulighed #2 og kigge paa et O/R
mapping tool som f.eks. NHibernate

Enterprise librarys data application block kan anbefales, den håndterer ud af boksen MS SQL / Oracle  og DB2, samtidigt er der noget community som har lavet til MySQL.

http://www.microsoft.com/downloads/details.aspx?FamilyId=5A14E870-406B-4F2A-B723-97BA84AE80B5&displaylang=en

Linket ovenfor er til .NET 2.0 men det findes også til .Net 1.1. hvis du skal bruge det.

kryptos >> Nu har jeg ikke lige læst så meget på det, men hvad kan det i korte træk ?

arne_v >> Koden er let at forstå selv for mig *GGG*, men der skal godt nok laves mange kopi/paste (mange linier) ved metoder der håndtere mange felter.

Det med O/R mapping skal jeg først have læst noget mere på for det fatter jeg til gengæld ikke en hat af :o(

/Websam

Data application block er et Data Access Layer, gør at du ikke skal skrive så meget kode for at kalde funktioner på din database. Samtidigt hjælper den dig til at holde din kode på et højere abstraktionsniveau, hvilket gør det lettere at bruge din kode på forskellige databasesystemer.

Ok men er det kan så også til alle sprog C#, Vb ect. ?

Det er skrevet i C#, men du kan jo bare kompilerer og bruge assembly i din VB applikation - igen problemer der.

en O/R mapper er noget hvor du kan skriver din data klasse med fields og
properties - O/R mapperen ordner saa SELECT/INSERT/UPDATE/DELETE
statements for dig

(i NHibernate angiver du mapningen klasse-tabel og field/property-felt i en
XML fil)

DAAB er slet ikke en loesning i den klasse - e'et i enterprise er meget lille
for DAAB

MS havde planlagt en O/R mapper for .NET 2.0/2005 kaldet Object Spaces, men den
blev annuleret

Jeg befinder mig i den situation lige nu at jeg ikke har tiden til at skal læse mere på tingene, så det med O/R mapper må vente til en anden god gang når jeg får tid til at studere platformen noget mere.

/Websam

IMHO, DAAB handler ikke om den helt store abstraktion, som en O/R mapper kan give og det er muligt at MS skriver/siger de har sådanne planer (men har de ikke altid planer og noget mindre handling), men det er i din situation bedre end at lave noget selv.

For lige at komme tilbage til trådens egentlige emne så skal jeg lige høre om ikke jeg kan gøre følgende for at styrre selve database valget :

1. Jeg har en klasse som indeholder connections til de forskellige databaser jeg vil benytte.

    Imports System
    Imports System.Data
    Imports System.Data.SqlClient
    Imports System.Data.OleDb

    Namespace DatabaseConnection
        Public Class DbClass
            '--- Erklære private fields
            Private _SqlConn As SqlConnection
            Private _OleDbConn As OleDbConnection

            '--- Default constructor
            Public Sub New()
                '--- Vælger hvilken type database der skal bruges.
                _SqlConn = MyClass.SqlConnect
            End Sub

            '--- Sql database forbindelse
            Public Function SqlConnect()
                Dim ConnectionString As String = "Data Source=Server;Initial Catalog=Min_Database;User Id=xxx;Password=yyy;"
                _SqlConn = New SqlConnection(ConnectionString)
                _SqlConn.Open()
                SqlConnect = _SqlConn
            End Function

            '--- Access database forbindelse
            Public Function AccessConnect()
                Dim StrPath As String = "D:\Sti_til_database\Min_database.mdb"
                Dim ConnectionString As String = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & StrPath
                _OleDbConn = New OleDbConnection(ConnectionString)
                _OleDbConn.Open()
                AccessConnect = _OleDbConn
            End Function
        End Class
    End Namespace

2. Jeg benytter så min factory klasse i datalaget til at kalde database forbindelsen.
3. Men er det en ok måde at gøre det på eller skal jeg benytte web.config filen til disse ting istedet for ?

Når der lige er styr på disse ting skal jeg have nogle svar så jeg kan få fordelt nogle point ud ;o)

/Websam

jeg ville bruge konfigurations fil

fordi det er ikke developerens opgave at vaelge database server - det er system
administratorens opgave

svar

Du skal som arne siger have de der ting ud i en konfigurationsfil. Og må jeg så igen anbefale at du giver Enterprise Library Data Application Block et seriøst kig, den løser lige præcist sådanne problemer og du slipper for at skrive den slags kode.

kryptos >>

Jeg skal nok kigge det noget nærmere efter i krogene, men lige nu har jeg nolge moduler som skal være færdige inden længe. Derefter skal jeg have skrevet en del om da det jeg har pt. ikke er så OOP som jeg gerne ville have at det var *GGG*, så der er det ikke udelukket at jeg kan bruge det ;o)

Hvis du skal have nogle point skal du lige smide et svar ;o)

/Websam

svar

Lige en sidste ting skulle "ConfigurationManager.ConnectionStrings" ikke ligge under namespacet "System.Configuration" ?

Når jeg forsøger at kalde :

    Dim objConnection As String = ConfigurationManager.ConnectionStrings("ConnectionString").ConnectionString

Får jeg bare en fejl der hedder :

    Name 'ConfigurationManager' is not declared.

Men med mindre at den ikke ligger under "System.Configuration" så kan jeg ikke lige se hvad fejlen skulle være ?

/Websam

Never mind jeg skal jo lige huske at jeg skal lave en reference til system.configuration .dll filen når jeg arbejder i et library DOOOOOHHHHH.

/Websam