We Keep Coding

C# Executing a query and getting data out of an Access Database (accdb) without using ACE.OLEDB

I'm writing a WPF application.
Trying to use the normal method of getting a connection returns an error similar to: "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."
ACE.OLEDB has never been installed on this machine so this error makes sense.
I'm trying to create this application in a way so that our users won't need to contact IT to have the application installed. Getting IT involved is a no go situation and the project will be abandoned.
Another team has an Access database (accdb) that I want my application to extract information (only read, no insert or update). I talked to the team and they won't convert this database back to an earlier version (mdb).
After my research I assume that installing ACE.OLEDB without using Admin privileges is impossible. Because of this and my application requirement of not requiring admin privileges I need to start looking for "Mutant"/Dirty solutions that don't involve ACE.OLEDB.
I tried using power-shell but I'm getting the same problems as I had with C# (requires IT to install ACE.OLEDB).
I have two potential solutions. One write a VBA script that opens up the database and dumps a query result into a file. My C# application would call this VB script and then parse the created file.
The second option is to create a new Access process using Process.Start(fullFilePath) and somehow pass the command to execute a query and somehow pass the results back to the executing application (either via a method return or first to a file).
How would you get the data out?
Is there a way for C# to duplicate the DB file and convert it from (accdb -> mdb)?
This is the second question I ask that is very similar.
C# Connecting to Access DB with no install
The difference between the two (to prevent this is a duplicate question) is that in the previous question I was looking for ways to install ACE.OLEDB without admin privileges while here I'm just looking for any other work around.

Found a workaround. It uses Microsoft.Office.Interop.Access found in NuGet.
var accApp = new Microsoft.Office.Interop.Access.Application();
accApp.OpenCurrentDatabase(#tests.DatabasePath);
Microsoft.Office.Interop.Access.Dao.Database cdb = accApp.CurrentDb();
Microsoft.Office.Interop.Access.Dao.Recordset rst =
cdb.OpenRecordset(
"SELECT * FROM Users",
Microsoft.Office.Interop.Access.Dao.RecordsetTypeEnum.dbOpenSnapshot);
while (!rst.EOF)
{
Console.WriteLine(rst.Fields["username"].Value);
rst.MoveNext();
}
rst.Close();
accApp.CloseCurrentDatabase();
accApp.Quit();

Extremely slow mysql connection establishment only when called from code

I am currently trying to do something that should be simple and straight-forward - connect to a database server, run a query, see if I get anything back and if so send it back to the user. This is the code I'm using to do it:
MySqlDataReader reader = MySqlHeaper.ExecuteReader(connectionString, $"SELECT * FROM table WHERE insertDateTime > '{DateTime.Now.AddSeconds(-1800).ToString("yyyy-MM-ddTHH:mm:ss")}'";
I have also tried this with a MySqlCommand and MySqlConnection object pair, and either way the result is the same - it takes approximately 7100ms to connect to the MySql server. I know that sounds like a problem that should be on ServerFault, but my testing tells me otherwise. When I use the command line MySql client to connect to my database server using exactly the same credentials and run exactly the same query I get my connection established and my data back in nothing flat. I don't know at this stage if it's a server setting or not, but here's what I've tried so far:
Rebooting the server
Restarting the MySQL server
Setting the skip_name_resolve setting to 1 in order to prevent reverse name lookups on connect
Using alternative means of querying the server (mysql command line client and MySQL Workbench)
Opening all AWS IAM permissions on the RDS instance to allow everything from the server
Nothing seems to be making any difference, so I'm at a loss to explain this terrible performance. It's also only happening when I open the connection. Running queries, inserts, what have you is lightning fast. Any suggestions anyone might have would be most helpful.

I would not expect IAM permissions to have any impact on performance. I would expect them to be either successful or not successful.
I would execute some diagnostic protocols to get more information.
1) Try a subsequent query, to see if it is an issue with the stack being initialized. Are subsequent queries faster?
2) Try a query that is just an identity query. Something that doesn't require any sort of IO.
3) Try a query from a different platform (maybe a scripting language like ruby or php)
Once you answer those it should help you narrow it down.

This is most likely caused by Connector/NET executing a slow WMI query to query connection attributes when opening the connection; this is logged as MySQL bug 80030.
As far as I know, this isn't fixed in newer versions of the driver, but you can work around it by switching to MySqlConnector, an OSS MySQL ADO.NET library.

.NET SQL Server connection issue - Maybe connection pool related

I am having a very strange problem and am hoping someone out there has had a similar experience.
My companies application for one client is getting "banned" from the SQL Server at the beginning of our application. The behavior is strange. I'll write it out in point form.
SQL Connections are created, data is retrieved, the connections are closed, talk to another datasource and then denied access to SQL Server.
Here's the long winded version:
.NET application connects to database multiple times. Gets some data, does some work. It then goes to get some more data and then gets an error that the "SQL Server cannot be found or access is denied". If the process is started over again without re-starting the app then no more connections are able to be made to SQL Server. All new connections result in "SQL Server cannot be found or access is denied". If the application is restarted then it will repeat the above process.
This is the first in 5 years of my experience with the software to have this problem. The application does have code written in Delphi 7. The dephi 7 / VBA code has not issues. My .NET code that performs the actual query looks like:
protected abstract DbConnection GetConnection();
protected abstract DbDataAdapter GetDataAdapter(DbCommand cmd);
protected abstract DbCommand GetCommand(DbConnection conn, String sql);
protected abstract DbCommandBuilder GetCommandBuilder(DbDataAdapter adapter);
public virtual DataTable Query(string sql)
{
var dt = new DataTable();
using (var conn = GetConnection())
{
try
{
using (var cmd = GetCommand(conn, sql))
{
using (var adapter = GetDataAdapter(cmd))
{
adapter.Fill(dt);
}
}
}
catch (Exception ex)
{
throw new SqlStatementException(sql, ex);
}
}
return dt;
}
It is my own quite and dirty DAL. When it is used it is using an OleDbConnection.
Note: Due to legacy code the connection string is configured for OleDbConnection. After taking a moment to review my code I do have the ability to change the connection type to SqlConnection. I haven't tried that yet.
On the client's machine I have not been able to reproduce the issue outside of the main application. I tried creating a little app that would make 100 calls back to back using the format above with an OleDbConnection but it executed successfully.
The failure in the main app happens in the same spot. That should give me a clue except I cannot make sense of it since it is making duplicate query, getting the same data. But I will say that the application talks to two data sources and transfers data from one to the other. Before it does the transfer it does some validation on the sources. So it talks to another database (proprietary file based) via ODBC and comes back successfully and then fails when trying to talk to SQL Server through OleDbConnection.
My suspicion is something is happening in the connection pool. That is causing a failure which in turns causes a denial of access.
Other interesting points. All worked fine for about a year, client got a new machine a couple of months ago, all work fine and then suddenly stopped. I put the application on another machine at the client's site and all worked well for a week and then the same issue appeared. We turned everything off on the client's machine but the issue persisted. I thought firewall but no luck there.
Any assistance is greatly appreciated.

Was gonna put this in a comment, but it got too big :-)
I see your connection-creating methods are abstract. This of course means that derivatives can do all sorts of bad things when they create the connection. I'd look there first.
One thing I found in a similar situation...if you're doing something in the code that creates the connection that makes the connection string unique, you won't be reusing those pooled connections. So...doing something like adding an "App=MyApp" + an incrementing number, date/time, or guid, it will destroy your ability to use pooled connections. When this happened to me, it took me forever to figure it out.
If your application was "slow enough" in the past, such that "old" pooled connections fall out of the pool, you might never see a problem...but then, say a customer gets hot new hardware...and blam...weird errors from nowhere! This might not be what's happening to you, but maybe it will give you some ideas about where to look. Good luck!

Security of printing SqlException.Message to console

While i've been debugging my code, I've been writing the output to the console so that I can monitor the errors and sql output. Naturally to protect against sql injection I have parameterised the queries where needed. After reading some articles online regarding the methods by which some injection attacking programs work, I now question whether the below practice is a good idea anymore.
Consider the following method.
public void MyQuery(int item_id)
{
string sql = "SELECT * FROM table WHERE item_id = #id";
SqlCommand sqlQuery = new SqlCommand(sql,conn);
sqlQuery.Parameters.Add("#id", SqlDbType.Int).Value = item_id;
try
{
conn.Open();
sqlQuery.ExecuteNonQuery();
conn.Close();
}
catch (SqlException ex)
{
Console.WriteLine(sql);
Console.WriteLine(ex.Message);
}
}
on my dev machine the console output is fine - no risk here. But if i were to leave the code as it is now when the application was live, would that potentially open up other avenues to exploit?
Im aware that if i were to have done MessageBox.Show(ex.Message); that would certainly be bad due to it being in your face.

You're deploying a WinForms application that connects to a SQL Server with credentials that apparently allow the application to write to that SQL Server.
Leaking SQL errors to the console is the least of your worries.
A malicious user can simply use the credentials used by your application to execute arbitrary SQL on that server.
Anything you deploy on a client machine must be considered insecure. Leaking queries is not the problem (the user could decompile your application or check its resources and inspect the SQL strings), the problem is that the client has a direct database connection.
If you want to prevent the client to know where the database is, what its credentials are and what queries your application executes, you must remove all this code from your application, and let the database stuff happen on a different machine altogether. You can then talk to this machine through a web service, for example.
Then the web service handles authentication, and refuses to execute any action for a user that isn't authenticated.

Simulate ORA-3113: end-of-file on communication channel

I have a C# Windows IIS server (Windows Server 2003) application connecting to an Oracle database hosted on Linux (10gR2 on Red Hat 5.3). Intermittetly, Oracle throws an ORA-3113: end-of-file on communication channel error. This screws up the OracleConnection object in C#. Then, any new OracleCommands that try to use the OracleConnection all fail saying the connection has been closed.
I have reviewed the Oracle trace files generated by this error and have isolated the problem to faulty network hardware and am working to fix it.
However, I need to make my C# code more robust and have it respond appropriately to this error by closing and not using that connection object anymore. It is easy to catch the exception in C#, but I cannot reproduce the network issue in the Development environment to prove my code works & cleans up after itself.
try
{
oracleCommand.ExecuteNonQuery();
}
catch(OracleException exception)
{
if(exception.Code == 3113)
CloseAndCleanup();
}
I have tried coding a PL/SQL trigger on a table that throws an ORA-3113 when I try to INSERT into the table.
CREATE OR REPLACE TRIGGER SCHEMA.TABLE
BEFORE DELETE OR INSERT OR UPDATE
ON SCHEMA.TABLE
FOR EACH ROW
DECLARE
CONNECTION_LOST_CONTACT EXCEPTION;
PRAGMA EXCEPTION_INIT (CONNECTION_LOST_CONTACT, -3113);
BEGIN
RAISE CONNECTION_LOST_CONTACT;
END;
This throws the right error, but doesn't corrupt the OracleConnection object in C#. I can still send commands to the OracleConnection and it works.
How can I accurately simulate the ORA-3113 error?

ORA-3113 means that a server process/thread that was assigned to a client unexpectedly died or was killed deliberately.
You can produce ORA-3113 error by manually killing a server process/thread. Killing session wont produce that error.
To reproduce that error you can take following steps:
1) Determine server process/thread associated with your session
select p.spid -- process ID
, s.program -- your oracle client
from v$process p
join v$session s
on p.addr = s.paddr
On the server side
2) Use orakill (windows) or kill -9 .. (Linux) to kill server thread/process
Windows example
c:\> orakill ORACLE_SID spid
After that you will get the ORA-3113 on the client side.

You can throw that exception manually from some PL-SQL code (like in a trigger).

You can kill your session.
alter system kill 'sid,serial#' immediate
You can query V$SESSION, or maybe V$MYSTAT and work it out but it's probably better to use sys_context and the USERENV namespace.
select sys_context('USERENV','SESSIONID') from dual
will get you the current session id (sid) and you can then query V$SESSION to get the serial#.
This procedure will kill the session that ran it:
create or replace procedure kill_my_session is
l_sid v$session.sid%type;
l_serial v$session.serial#%type;
begin
select sid, serial#
into l_sid, l_serial
from v$session
where sid = (select sys_context('USERENV','SESSIONID') from dual)
;
execute immediate 'alter system kill session '''|| l_sid
|| ',' || l_serial# || ''' immediate';
end;
Of course, you could always just do it manually, which might be easier.

I know the initial question was targeting system setup with Oracle on Linux. For others out there running the Oracle database XE on Windows there is an easy way to reproduce this.
Go into the running Services (found in Control Panel\System and Security\Administrative Tools) and simply stop the process named OracleServiceXE. This will also cause ORA-03113 to appear.