4
mad-sy
29d

Fuck Oracle, fuck you oracle! The stupidest shittiest worst nightmare company with the most user-unfriendly, productivity-killing, illogical, stupid pile of software garbage products ever! And unfortunately I want to extends my worm-fucks to all Oracle employees and maintainers and to the whole fucking community of shit that made up oracle-community and to every conscious being who ever liked, enjoyed or have found the slightest genuine interest of any product tagged "oracle".

I installed the pile of shit a.k.a Oracle 18c and imported a dumb file locally, everything was working in the slightest amount of the word (fine) before it turns to nightmare. I created a C# client to call a stored procedure in that shit of a database engine. I kept getting error related to the parameter types, specifically one which is custom type of Table of numbers. It turns out that the only of doing this is through that shit they called (unmanaged driver), the "managed" doesn't support custom types. So I had to install another package of shit they call (odbc universal install) "universal my a$$ by the way", at that moment, where everything just crashed and stopped working. I spent 3 hours trying to connect to the fucking database to no avail. I shockingly found a folder in my desktop folder called (OracleInstallation) and all windows services related to oracle installation "suddenly" got somehow (re-routed) to that folder.
In conclusion, fuck oracle.

Comments
  • 3
    Yep, Oracle is the hautest of haute garbage.

    Try layering dapper over it. It should allow you to use the managed client and at least have types on the right side of the operation. Run the database out of docker for local and it should dramatically reduce your entropy.
  • 1
    @SortOfTested I tried using ado.net, I was trying to use EF Core but I gave up. I get the same error with ado.net. I think dapper is too built on top of some of those horrible oracle "drivers" so it's kind of pointless adoption dapper in my case.
  • 1
    @mad-sy
    We hit similar issues when we began autogenerating our data connectors for our client integrations. This was our solve.

    The perf hit of ODBC is the greater evil, at least to my mind. For most non-MSSQL dbs, the happy path will unfortunately be to allow the left side to be a dataframe, and the output to be whatever your coercable T is. Dapper will at least eliminate the boilerplate, so the workflow becomes query/sproc -> dataframe -> T.
Add Comment