AZURE CodeFirst Deploy TimeOut

verwendetes Datenbanksystem: <Azure SQL> -> EF 6.1 -> CodeFirst

Liebe Leute

Wenn ich mein Projekt deploye auf AZURE erhalte ich immer ein TimeOut (SQL AZURE).
(Beim erstellen der DB, Seed wird erst gar nicht aufgerufen)

Nach langem Testen und Debugen ist mir dabei folgendes aufgefallen:

=> DB wird erstellt ohne Tabellen
=> TimeOut.

Wenn ich die DB aber per SQL selbst erstelle, danach den Initializer aufrufe, klappt alles.

Ich behaupte also dass die Eigenschaft CommandTimeOut für die Erstellung der Datenbank auf dem Context ignoriert wird. (Bei Azure dauert das anlegen einer DB gut mal 40-50 Sekunden, default ist 30 Sekunden TimeOut).

Kann das jemand bestätigen oder hat ähnliche Erfahrungen ?

Beste Grüsse

Diräkt

Kann ich nicht bestätigen.
Ich bau meinen SqlConnection-String via SqlConnectionStringBuilder (SqlClient-Klasse) und setze hier das Timeout - funktioniert in einer WebRole einwandfrei.
Die Werte konfigurier ich über die AppSettings statt direkt in der WebConfig als ganzes.

Hallo Abt

Danke für Deine Antwort.

Hm, es gibt ja 2 Einstellungen, einmal die vom ConnectionString für die Verbindung und dann noch das CommandTimeout. ( Führen jeweils zu einem anderen Fehler, wenn Vorgang länger dauert )

Selbst wenn ich lokal auf die AZURE DB zeige, und mein Initializer aufrufe erhalte ich den TimeOut Fehler.

m_db.Context.Database.Initialize(force);

Wenn ich vorher aber ein SQL STATEMENT absetze:

CREATE DATABASE ...

Danach den Initializer laufen lasse, klappt es ohne den Timeout fehler.
Meine DB hat etwa 10 Tabellen und vielleicht 50 Datensätze initial. Also absolut lächerlich.

Eine Idee ?

Der Fehler lautet:

Fehlermeldung:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. This failure occurred while attempting to connect to the routing destination.

( Der ConnectionString Timeout Fehler würde etwas anders lauten, weiss gerade nicht mehr... )

EDIT:
=> Vielleicht eine noch wichtige Anmerkung 😃
Das besagte Verhalten habe ich erst seit ich AZURE 2.6 und EF 6.1.3 verwende