API Returns EF Core records locally, but not when hosted in Azure-CodePudding

I have a web app (api) in .NET 5 (core). It accesses an Azure DB and has dozens of tables that all work well. However, 1 api request always returns 0 records, but only when the api is hosted in an Azure app service. When it runs locally, in debug or release, it works as expected.

The web request never returns errors, all 200's, but no records.
Other queries of the same table produce expected results.
When I put logging in after the db call [a simple ctx.MyTable.Where(i => id > 0)] and it logs that no records are ever returned.
When I run the api locally (still using the Azure DB), it always works.
I've tried Debug and Release.
I've changed the Azure app service to .NET 5, .NET 6 (Early), 32-bit, 64-bit.
I've updated all NuGet packages to the latest.
Let me add, I've logged the DB connection string in local and host, debug and release, it's always the same.

This ones really got me. It's a big project so I can't show code...but I can't even think of scenarios that could induce this sort of behavior.

CodePudding user response：

It's hard to say without checking the code or error whether it's a database problem or a code first problem. Try changing the entity framework connection string. Also try requesting your data in list rather db object (if you are doing) using -

public IEnumerable<Conversation> GetDBname()
{
    return db.DBname.ToList();
}

Make sure you use the Azure connection (SQL Database connection strings for ADO.NET) in the Web.config file.

 <connectionStrings>
    <add name="MyAzzureConnection" connectionString="paste the connection string from Azure here" />
 </connectionStrings>

Check this Deploy an ASP.NET app to Azure with Azure SQL Database document and Using Web API 2 with Entity Framework 6 for more information.

You should also check this Web API implementation - Best Practices Microsoft document for clarification.

CodePudding user response：

OK, I got it! Somewhere down the calling tree a date was being used where the time was not trimmed off in the query, but was in the logging. So it looked from the logs like the date being used was the same on Azure as it was local. In fact, it was n-timezones different between the two.