We Keep Coding

WCF Service not connecting to MSSQL

I made a xamarin android app that is supposed to connect to a database. I created a WCF Service that is hosted at a specified address. I then used SLsvcUtil.exe to create a proxy client to call various methods in my service. Previously I had zero issues connecting to the database but after updating my service, it can't even connect to the database. I receive the following error:
System.Reflection.TargetInvocationException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections.
The machine that is hosting the database has firewall turned off. The WCF Service is hosted on a seperate machine. I checked to see if mssql is accepting remote connections and it is. I have TCP/IP protocols enabled. I don't know if it will help but I am using LINQ to connect to the database and using visual studio. I can see that with using LINQ to SQL, a connection is seen on my machine (which is hosting the database).
Anyone have an idea?

i did some tests about connecting android apps to wcf, and all my tests fails, i recommended to you to change the approach, use REST api or web API to communicate android device to .NET backend.

EF + Multiple transaction, Multiple Context

I have been trying everything to make this situation working, but unable so far
Entity Framework
XUnit (testing library)
2 DbContext (2 differents databases, 2 connections strings)
Situation: Run integration test with AutoRollBack feature (The AutoRollback feature manily wrap the code in a Parent transaction which is rolled back at the end of the test)
The Test looks like:
[AutoRollBack]
Test(){
Operation1 against DB1
Operation2 against Db2
}
I enabled MSDTC on both SQL Servers, used the DTCPing tool to confirm that the communication is ok between them
I Enabled Distributed Transaction in Inbound and Outbound Firewall in both servers
I Added distributed Transaction in Allowed Programs in Firewalls of both servers
Both servers can ping each other using Netbios name
But the 2nd operation in the Test will always return "the Underlying provider failed on Open"
The MSDTC transaction manager was unable to pull the transaction from the source transaction manager due to communication problems. Possible causes are: a firewall is present and it doesn't have an exception for the MSDTC process, the two machines cannot find each other by their NetBIOS names, or the support for network transactions is not enabled for one of the two transaction managers. (Exception from HRESULT: 0x8004D02B)
I am looking for another way of debugging the problem. is there a way to have some logs of some sort for example

DTC issues using Oracle and .NET 4 - RM_COMMIT_DELIVERY_FAILED_DUE_TO_CONNECTION_DOWN

First a little intro to our setup:
WCF based app with EF 4 context injected using Unity (no singleton)
Oracle running on a seperate physical machine
NServiceBus handling messages that access Oracle through the same context as above
The problem we are experiencing, only on our UAT environment, is that we cannot send multiple messages without receiving distributed transaction locks on DTC. The DTC trace tells us this:
1. TRANSACTION_COMMITTED
2. RM_ISSUED_COMMIT
3. RM_ISSUED_COMMIT
4. RM_ACKNOWLEDGED_COMMIT
5. RM_COMMIT_DELIVERY_FAILED_DUE_TO_CONNECTION_DOWN
Any bright ideas?

It seems the problem lies within our client app WCF configuration.
Deep down in our framework we are setting TransactionFlow = true which tries to setup a transaction scope starting from the client. If we run our request and fire of a NServiceBus message we loose the link with our client and cannot commit the transaction.
So TransactionFlow = false in app.config saved us.

With sql service broker what happens if the target application crashes?

How will the target application get the messages send to it while it was unresponsive, stopped and restarting? Will they be sent again automatically when it comes back online?
How would you implement this with EF and C#? Where are the tutorials!

Service Broker sends from SQL Server to SQL Server. The protocol used is fully resilient to crashes, messages stay in the sender's sys.transmission_queue until acknowledged by the target, and the target only acknowledges them after committing them into the destination service queue. SQL Server also handles everything related to transient failures: unresponsive destination, network partitioning, servicing/patching outages. All this is handled by SQL Server itself, as it guarantees Exactly Once In Order delivery.
Now what happens if your application crashes, ie. while processing a RECEIVE statement, is very simple: you interact with Service Broker through T-SQL, in a database transaction context. If the application crashes, the normal behavior of ACID database transactions kick in: since the transaction did not commit, it will be rolled back and the application will have a chance to process the message again, after restart.
So, from your application point of view, you only interact with a database, queues and tables and all, within a database transaction context. Your questions are the same as 'what happens to an INSERT if the application crashes?'

Connection limt reached issue [C014] in Attunity

I have a project that connects to a RMS file system through Attunity (Version 1.0.0.8). The RMS file is in a different server. The connection pool on both client and service is 10 (Max connection pool size). When we hit the server from the client, we sometimes get the error:
C014: Client connection limit reached - try later.
I would like to understand whether this error is related to Server overloaded or any issues on the Client side. I am sure that the client code that I am using to connect to the server is properly opening and disposing the connection.

This sounds like a problem we were having. We were running Attunity on OpenVms and we were maxing out the number of DECNET connections to Attunity between our nodes; the underlying problem was with our client. The clients in this case would induce a longstanding transaction or had problems releasing their connections back to the pool. We fixed the issue by eliminating the longstanding transactions and then finding the bug in the clients where the they would not release their connection. Unfortunately, all of our clients are implemented in Java and Cobol, so I don't have any .Net specific advice.