C# program többféle adatbázissal
2005-02-24T09:49:13+01:00
2005-03-18T15:32:27+01:00
2022-07-27T04:28:41+02:00
  • Developer tools, technical documentation and coding examples

    Úgy tűnik, hogy a .NET 2.0 ad rá valamiféle megoldást...
    Mutasd a teljes hozzászólást!
  • SZiasztok, most ismerkedem a C# adatbázis programozással és lenne egy kis gondom.

    DataSet objektumba töltenék több DataTable objektumot, egyszerre több SELECT utasítást használva (access adatbázis). Ami érdekes, hogy MS SQL adatbázissal faszán müködik, de accessel már nem

    A hibajelzés mindig a myOleDbDataAdapter.Fill(myDataSet) sornál kapom.

    Ha valaki tud segíteni azt megköszönném!
    Mutasd a teljes hozzászólást!
  • Jaja, egyébként az ODP.NET lekérdezésekre észrevehetően gyorsabb, mint az OracleClient. Insert-re tökmindegy.

    Még valami eszembe jutott:
    DataReader.GetValues(object[])

    A legtöbb implementációban a DataAdapter is ezt használja legbelül.

    Ahhoz, hogy ez Int16-ot adjon vissza MSSQL adatbázisban SMALLINT típusú mező ajánlott. Ez tényleg 16 bites. Oracle esetén NUMBER(4, 0) kell, de ez csak -9999..9999 közötti értékeket tárol. Oracle esetén könnyen oda juthat az ember, hogy minden szám System.Decimal-ként jön fel, és a konverziók miatt jelentősen lassulhat a kód. Például a kódban egy int típusú változónak adunk értéket egy dobozolt System.Decimal-ból, ami a DataSet-ben van, és valójában nem is sejtjük, hogy az a dobozolt objektum nem System.Int32, mint ahogy számítunk rá, hanem valójában egy System.Decimal, mert az adatbázisból úgy jött fel a rossz típusmegválasztás miatt...

    Szóval gyors adatelérésnél erre is nagyon oda kell figyelni. Mármint a helyes típus megfeleltetésre .NET típusok és az adatbázis által támogatott típusok között.
    Mutasd a teljes hozzászólást!
  • Ilyesmin segithet pl. az - mint Cimby is irta - adapter pattern és az abstract factory együttes alkalmazása.
    Mutasd a teljes hozzászólást!
  • A paraméterek hozzaadasat eleve eleg nehez dolog adatbazisfuggetlenul megoldani, mert mar az sql-ben is mashogy van jelolve pl. Oracle es MSSQL alatt.

    Az ODP.NET-rol csak annyit, hogy tenyleg tobbet tud mint az MS sajat provider-e, de mivel nem MS tobb az ilyen apro elteres a tobbi provider-tol.

    A sima OracleClient pl. szerintem jobban hasznalhato interface-en keresztul.

    Mutasd a teljes hozzászólást!
  • Próbáltál már egy Command-hoz paramétereket hozzáadni úgy, csak ezeket az interfészeket használod? Megsúgom, hogy segédosztály nélkül reménytelen a helyzet...

    Mert ugyebár a ParamBinding az egy nagyon jó dolog, SQL injection és atomtámadás ellen is véd.

    Ja, és van még egy dolog, ami fontos a tranzakciókezeléssel kapcsolatban.
    ODP.NET -ben egy Command Transaction propertijét nem szabad beállítani, mert automatán átveszi a konneksöntől. SqlClient esetén meg kötelező beállítani ha a konneksönön nyitottál tranzakciót. Erre például nem ad megoldást az interfészes dolog, mert az csak addig jó, ha mindenki rendesen implementálja a dolgait, de sajnos nem így van.

    De van még adatbázisspecifikus dolog: a IDataReader.GetSchemaTable() metódus más táblaszerkezetet ad vissza az ODP.NET megvalósításban, mint az SqlClient megvalósításban.
    Mutasd a teljes hozzászólást!
  • ja tenyleg foleg az
    Mutasd a teljes hozzászólást!
  • Köszi a gyors válaszokat. Megpróbálok elmélyedni az általatok írtakban. Egyébként valószínűleg egy Powerbuilder programot kell átírni szervízre úgyhogy biztos lesznek még buktatók. Főleg, hogy most ismerkedünk a .net-el.
    Mutasd a teljes hozzászólást!
  • Annyit tennék hozzá Cimby megoldásához,
    hogy ebben az esetben a wrap-elésre nincs igazán szükség, mert az ADO.NET összes lényeges osztályát egységes interface-en keresztül el tudod érni.

    pl. IDbConnection, IDataAdapter, IDbCommand

    Csak a létrehozásról kell gondoskodni
    pl. Abstract Factory pattern-el.

    A problémás dolog tényleg az, hogy a sql-ben lehetnek apró különbségek.
    Mutasd a teljes hozzászólást!
  • ODBC-vel kapcsolatban nincs tapasztalatom, de szerintem mérd ki a sebességbeli különbséget egy ODBC-s, és egy natív adatbáziskapcsolat között, és oszd meg velünk is.

    Lehet, hogy nem is lesz olyan egetverő a különbség, bár kituggya. Lényeg, hogy mérjél lekérdezést, meg módosítást; fontos, hogy ugyanarra az adatbázisra menjél be kétféleképpen.

    Mutasd a teljes hozzászólást!
  • A DataSet alapból adatbázisfüggetlen, és így is van rendjén. k.r.i kolléga szerintem az adatbázishozzáférés absztrahálására kíváncsi, és nem az adatmegjelenítésre. Két lehetséges megoldást már adtunk neki.
    Mutasd a teljes hozzászólást!
  • public abstract class MyConnection { public abstract MyCommand.CreateCommand(); public abstract void Open(); // stb. } public abstract class MyCommand { public abstract string CommandText { get; set; } public abstract MyDataReader ExecuteReader(); // stb. } public class MSSQLConnection : MyConnection { private System.Data.SqlClient.SqlConnection m_Connection; public override MyCommand.CreateCommand() { return new MSSQLCommand(m_Connection.CreateCommand()); } public override void Open() { m_Connection.Open(); } // stb. } public class MSSQLCommand : MyCommand { private System.Data.SqlClient.SqlCommand m_Command; internal MSSQLCommand(System.Data.SqlClient.SqlCommand command) { m_Command = command; } public override string CommandText { get { return m_Command.CommandText; } set { m_Command.CommandText = value; } } public override MyDataReader ExecuteReader() { return new MSSQLDataReader(m_Command.ExecuteReader()); } // stb. }

    A wrap-pelésnek az az előnye, hogy egységes a hozzáférés az adatbázisokhoz, hátránya viszont, hogy adatbázisspecifikus SQL-t nehézkes vele használni, vagyis célszerű a lehető legszabványosabb SQL nyelvjárást használni, bár néha az sem elég.

    A Data Access Application Block és a wrap-pelés között igazából az a különbség, hogy más szinten absztrahálja el a dolgokat.

    Az adatbázisspecifikus nyelvjárások használatát persze nem fogod tudni kikerülni (gondolj csak egy rekord zárolására, 'for update', 'with updlock', stb.), maximum elrejteni valahova. Az ilyesmit a Data Access Application Block -ban tudod könnyebben megcsinálni.
    Mutasd a teljes hozzászólást!
  • A technikai oldalat nezve meg disconnected datasetek hasznalata (DataSet osztaly es baratai), .NET DataBinding mechanizmus, DataAdapter-ek.
    Mutasd a teljes hozzászólást!
  • Főleg az Adapter...
    Mutasd a teljes hozzászólást!
  • http://crlab.com/unidirect/

    Nem tudom, hogy állnak most, de tavaly, amikor erre szükségünk lett volna, akkor még olyan bugos volt, hogy inkább írtunk egy sajátot. Azóta persze nagyon sok minden megváltozhatott. Szvsz érdemes kipróbálnod.
    Mutasd a teljes hozzászólást!
  • egyrészt: Data Access Application Block

    másrészt: az sw rétegzése

    harmadrész: egyébb desing&practices az ms-nel

    negyedrész és nagyon: design patterns (pl factory)
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Kellene írnom egy programot, aminek többféle adatbázissal is kommunikálnia kell. Viszont úgy néz ki, hogy lesz olyan felhasználó akinek az adatbázisát egy vpn-en keresztül éri el a program. Tehát hogy érjem el azt, hogy egységes felületen gyors legyen a kommunikáció. Az adatbázisokhoz lenne natív dll ami jó gyors (gondolom), de eléggé elbonyolítaná a programot (nem is beszélve a bővíthetőségről) ha azt kellene figyelgetnem, hogy mikor milyen adatbázishoz kapcsolódok. Az ODBC jó lenne, de félek, hogy lassú. Szóval ha valaki csinált már ilyet akkor ossza meg a tapasztalatait pls.

    Köszi.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd