If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Re: Ef stored procedure return null

Start with the basics:
1) Are you SURE you're connected to the right database? - I ask because you're using a FQN to access the table, which means the tables you're accessing may not be the tables in the database you're connected to... is there a reason you're using an FQN?
2) Is the table empty? Because you're using a FQN, it's possible the table you're actually using could be empty.
3) Does the ID you're passing in exist?

-tg

Edit...
I was going to suggest changing
[IPADDRESS].[MASTER].[dbo].[EMPLOYEES]
to just dbo.EMPLOYEES ... but then I notice... you're using the master database? ?! O.O

Re: Ef stored procedure return null

Originally Posted by FunkySloth

1. Yes I am connected to the right database, and as you notice I'm using the ip address due to I am accessing the database to other server.

Is the stored procedure accessing a remote database? If you execute the stored procedure from within SSMS does it return the correct results? Is your connection string using integrated security or a hard coded username and password? If integrated security then you need to make sure the user your web application runs as can execute the stored procedure.

Re: Ef stored procedure return null

Yes it is accessing a remote database and using a hard coded username and password connection string. When using SSMS it does return the correct record. Is there any problem about using the master database?

Re: Ef stored procedure return null

Originally Posted by FunkySloth

Yes it is accessing a remote database and using a hard coded username and password connection string. When using SSMS it does return the correct record. Is there any problem about using the master database?

The master database is a system database, more accurately it is the system database as it is the database that controls and configures your SQL server, it isn't intended to be used as a database for your own things. https://docs.microsoft.com/en-us/sql...aster-database is possibly worth a quick look as it explains a bit more about it.

A brief summary though is that it isn't intended for you to use as your own database, it has fairly specific options set (such as simple logging) which make it unsuitable for a normal database workload, problems with the master database can leave you SQL Server unable to start (which in this case would mean unable to get at your data, restoring your damaged master would prevent the server starting).

The normal practice is to create your own database on the server to store your data in, not just shoving it into master.

I must admit to having never used EF with a linked server before so I am not sure if that could be part of the problem, is there a need to use a linked server rather than access the server directly? Would it be possible to test connecting to the other server directly? Also if you have a linked server why not use the remote server's name rather than the IP Address?

Re: Ef stored procedure return null

So I guess I'd better use directly the server rather than linked it to my Stored Procedure, and oh, don't worry I'm not using the Master System Database, that's a different Master Database.

And I think I'd better create the Model of the linked server instead, so I could access the data easier. Though having multiple EF Model does it slow the performance of the system?

So you have a database called Master on your SQL server? I have honestly never even tried to do that!

Having multiple EF models isn't really going to affect the performance, the only difference it is likely to make is in terms of the compiled application size and I doubt it will add that much impact. The bigger difference is going to be down to database and network speeds, accessing a database directly rather than going to one database and having it go to the other database is probably a faster option anyway.