[VB.NET] Entity Data Model verbinden met Oracleserver

[SimonBlok]

Ik heb een Visual Basis .NET applicatie. In deze applicatie heb ik een Entity Data Model staan met hierin de datastructuur die ik in de applicatie gebruik. Alle Entities zijn tabellen in een Oracle database.

Bovenstaande werkt allemaal prima op mijn ontwikkel-pc. Hier heb ik de ODP.NET connector op geïnstalleerd. Op een willekeurige andere PC, zonder ODP.NET, werkt het niet meer, ook na installeren van ODP.NET werkt het niet. Dit is de melding die ik krijg: "the specified named connection is either not found in the configuration or is not valid".

Ik heb van alles geprobeerd, DLL's als referentie toegevoegd, verschillende formaten van de connectionstring en de volledige Oracle Cliënt geïnstalleerd op de cliënt-pc, maar niets helpt.

Wie kan mij vertellen hoe ik een VB.NET applicatie met koppeling naar een Oracle database kan deployen naar een cliënt pc?

[RobIII]

the specified named connection is either not found in the configuration or is not valid

Ik heb van alles geprobeerd, DLL's als referentie toegevoegd, verschillende formaten van connectionsstring en de volledige Oracle Cliënt geïnstalleerd op de cliënt-pc, maar niets helpt.

Als je eens begint met te configfile (gokje: app.config) na te lopen? Post 'm desnoods hier eens?

[ Voor 6% gewijzigd door RobIII op 07-10-2013 16:15 ]

[SimonBlok]

De connectionstring (inde app.config inderdaad) heb ik meerdere keren aangepast. De versie die gegenereerd werd door de Enitity model Wizard is als volgt:

code:

  <connectionStrings>
    <add name="Entities" connectionString="metadata=res://*/Datasets.EntitiesGlovia.csdl|res://*/Datasets.EntitiesGlovia.ssdl|res://*/Datasets.EntitiesGlovia.msl;provider=Oracle.DataAccess.Client;provider connection string=&quot;data source=***/***;password=***;user id=***&quot;" providerName="System.Data.EntityClient" />
  </connectionStrings>

In bovenstaande connectionstring is de providerName ingesteld op System.Data.EntityClient. Met dit gegeven heb ik verschillend referenties toegevoegd en verschillende oplossingen geprobeerd, maar niets werkt.

[ Voor 16% gewijzigd door SimonBlok op 07-10-2013 16:31 ]

[Alex)]

De provider in je connection string is van het type EntityClient, maar deze client is niet veel meer dan een soort koppeling tussen je datamodel en een specifieke databaseserver.

In de connection string staat de volgende provider gedefinieerd: Oracle.DataAccess.Client. Is deze beschikbaar op je doel-pc?

[SimonBlok]

Ik heb het inmiddels voor elkaar. Heel stom, maar wat ik nog niet geprobeerd had was het installeren van de volledige Oracle Cliënt met exact dezelfde versie als op de ontwikkel-PC. Het werkt nu, maar eigenlijk is dit niet wenselijk. ik heb namelijk geen zin om op elke cliënt een softwarepakket van 250 MB te installeren op een applicatie van 5 MB te kunnen draaien.

Ik ga nog eens proberen om wat DLLetjes toe te voegen zodat de cliënt wat eenvoudiger klaar te maken is.

[EfBe]

SimonBlok schreef op donderdag 10 oktober 2013 @ 08:54:
Ik heb het inmiddels voor elkaar. Heel stom, maar wat ik nog niet geprobeerd had was het installeren van de volledige Oracle Cliënt met exact dezelfde versie als op de ontwikkel-PC. Het werkt nu, maar eigenlijk is dit niet wenselijk. ik heb namelijk geen zin om op elke cliënt een softwarepakket van 250 MB te installeren op een applicatie van 5 MB te kunnen draaien.

Ik ga nog eens proberen om wat DLLetjes toe te voegen zodat de cliënt wat eenvoudiger klaar te maken is.

Dat werkt niet, je moet ODP.NET installeren per client. Oracle heeft wel een Managed ODP.NET, die zonder Oracle CLI (de Oracle client in Java) werkt. http://www.oracle.com/tec.../dotnet/index-085163.html Echter, die heeft iets andere type mappings, en geen idee of die goed met entity framework werkt.

De managed driver is op sommige punten wat anders: http://docs.oracle.com/cd...n.121/e41125/intro004.htm maar wellicht heb je daar geen last van. EF support schijnt er in te zitten, alleen is EF support in ODP.NET niet al te best (wellicht dat ze iemand anders het hebben laten herschrijven, maar hun broddelwerk in 11g's versie was niet best)

[ Voor 17% gewijzigd door EfBe op 10-10-2013 10:52 ]

[Daspeed]

Hier zijn we deze week gemigreerd van de unmanaged ODP.NET driver naar de managed variant. Buiten wat ander gedrag hier en daar en wat initiële problemen met clobs > 4000 karakters lijkt het een redelijk probleemloze migratie. Wij gebruiken overigens NHibernate i.p.v. Entity Framework.

[EfBe]

Welke problemen zag je met clobs > 4000 chars trouwens? (Dit ivm wel/niet specifieke codepaths for de managed provider in onze code). Ik kende alleen de xmltype die mist.

[Daspeed]

Onze software draait op verschillende versies van Sql Server en Oracle. Grote tekstvelden worden door ons met NHibernate gemapped met NHibernateUtil.StringClob.SqlType.

Na de migratie van unmanaged naar managed hadden we een unit test die faalde met de volgende exceptie:

code:

Oracle.ManagedDataAccess.Client.OracleException: ORA-01483: invalid length for DATE or NUMBER bind variable

In deze test wordt een string van 9000 karakters ge-insert. Bij aanpassen naar 4000 karakters slaagde de unit test wel.

Om de managed Oracle provider te kunnen gebruiken in NHibernate waren we geswitched van NHibernate.Driver.OracleDataClientDriver naar NHibernate.Driver.OracleManagedDataClientDriver. Om bovenstaande test te laten slagen met 9000 karakters moesten we het gedrag van die laatste provider aanpassen naar zoiets:

C#:

class CustomOracleClientDriver : NHibernate.Driver.OracleManagedDataClientDriver
{
    protected override void InitializeParameter(IDbDataParameter dbParam, string name, NHibernate.SqlTypes.SqlType sqlType)
    {
        base.InitializeParameter(dbParam, name, sqlType);
        if (sqlType is NHibernate.SqlTypes.StringClobSqlType)
        {
            ((OracleParameter)dbParam).OracleDbType = OracleDbType.Clob;
        }
    }
}

[edeboeck]

SimonBlok schreef op donderdag 10 oktober 2013 @ 08:54:
Ik heb het inmiddels voor elkaar. Heel stom, maar wat ik nog niet geprobeerd had was het installeren van de volledige Oracle Cliënt met exact dezelfde versie als op de ontwikkel-PC. Het werkt nu, maar eigenlijk is dit niet wenselijk. ik heb namelijk geen zin om op elke cliënt een softwarepakket van 250 MB te installeren op een applicatie van 5 MB te kunnen draaien.

Ik ga nog eens proberen om wat DLLetjes toe te voegen zodat de cliënt wat eenvoudiger klaar te maken is.

Heb je al kunnen testen of het niet gewoon met een security-setting te maken heeft? Het zou kunnen dat, als je de volledige client installeert, er een opening in de firewall gemaakt wordt (bijvoorbeeld), of een bepaalde tunnel opgezet wordt.

Just my 0,02...

[SimonBlok]

Ik heb inmiddels het één en ander geprobeerd, verschillende sets van DLL's. Veel oplossingen geprobeerd die op deze lijken: http://www.splinter.com.a...t-to-access-oracle-from-c

Dit is een set van de volgende DLL's:

- oci.dll
- Oracle.DataAccess.dll
- oraociicus11.dll
- OraOps11w.dll
- orannzsbb11.dll
- oraocci11.dll
- ociw32.dll

Ik moet ook toegeven dat ik soms het idee heb dat ik geen idee heb waar ik mee bezig ben op dit gebied; het probleem is echter dat ik nergens (en dan ook echt nergens, want ik ben zo'n beetje het hele internet rond geweest) een goede instructie kan vinden hoe ik een VB.NET applicatie met Oracle ondersteuning en gebruik maken van het Entity Framework, kan deployen zonder dat ik de volledige Oracle-cliënt moet installeren. Voor nu is dit een oplossing, maar eigenlijk is dit niet wenselijk.

[edeboeck]

Heb je de gelegenheid om te testen met VM's? In dat geval zou je snapshots kunnen maken van je systeem vóór installatie van de client en nadien... op die manier weet je dan wat de installatie juist aanpast (op deze pagina - die wel al wat ouder is - vind je een aantal tools). Zelf had ik vroeger ook zo een programmaatje geïnstalleerd staan, maar ik weet de naam absoluut niet meer.
Als je zowel filesystem- als registry-changes trackt, dan heb je (op de false positives na) een correct beeld wat de installatie aanpast. Wie weet kom je op die manier iets te weten...

Voor dit systeem is het wel zeer gemakkelijk als je met VM's kan werken... zo kan je sneller verschillende tests uitvoeren door terug te schakelen naar een vorig VM-snapshot).

[ Voor 11% gewijzigd door edeboeck op 10-10-2013 15:04 . Reden: toevoeging VM's ]

[EfBe]

Daspeed schreef op donderdag 10 oktober 2013 @ 14:35:
Onze software draait op verschillende versies van Sql Server en Oracle. Grote tekstvelden worden door ons met NHibernate gemapped met NHibernateUtil.StringClob.SqlType.

Na de migratie van unmanaged naar managed hadden we een unit test die faalde met de volgende exceptie:

code:

Oracle.ManagedDataAccess.Client.OracleException: ORA-01483: invalid length for DATE or NUMBER bind variable

In deze test wordt een string van 9000 karakters ge-insert. Bij aanpassen naar 4000 karakters slaagde de unit test wel.

Om de managed Oracle provider te kunnen gebruiken in NHibernate waren we geswitched van NHibernate.Driver.OracleDataClientDriver naar NHibernate.Driver.OracleManagedDataClientDriver. Om bovenstaande test te laten slagen met 9000 karakters moesten we het gedrag van die laatste provider aanpassen naar zoiets:

C#:

class CustomOracleClientDriver : NHibernate.Driver.OracleManagedDataClientDriver
{
    protected override void InitializeParameter(IDbDataParameter dbParam, string name, NHibernate.SqlTypes.SqlType sqlType)
    {
        base.InitializeParameter(dbParam, name, sqlType);
        if (sqlType is NHibernate.SqlTypes.StringClobSqlType)
        {
            ((OracleParameter)dbParam).OracleDbType = OracleDbType.Clob;
        }
    }
}

Ah dank je. Als dat het is dan voorzie ik voor mijn code geen problemen (omdat we al OracleDbType via reflectie / IL emit gebruiken en niet DbType, zoals NHibernate doet)