Azure Datenbank / techn. Frage

  • VB.NET

Es gibt 3 Antworten in diesem Thema. Der letzte Beitrag () ist von Coldfire.

    Azure Datenbank / techn. Frage

    Tach auch,
    wir haben einen Dienstleister, der hat für uns ein Web Frontend mit angebundener Azure Datenbank (SQL Server) prgrammiert.
    Das war vor etwa 4 Jahren.

    Seit jeher habe ich eine ODBC Verbindung auf diesen Server, um die Daten per Access aufzubereiten und zu reporten.
    Seit letzter Woche habe ich Probleme mit der Verbindung. Das äußert sich so, dass ich 10/15 Minuten normal arbeiten kann, dann plötzlich die Verbindung weg ist, und bei erneuten Versuchen der Server nicht erreichbar ist. Nach etwa 30 Minuten geht alles wieder wie gehabt.

    Unsere IT hat keinen Ansatz wo sie suchen soll. Händisch wurden weder in unserem Netz Updates gefahren, noch auf meinem Rechner - auch an der SQL Datenbank wurden keine Änderungen vorgenommen.

    Unser Dienstleister ist nun der Meinung, dass meine Abfragen in Access soviel Traffic verursachen, dass mich die Azure DB aus Sicherheitsgründen für gewisse Zeit sperrt.

    Meine Frage: gibt es solche Sicherheits-Technik?

    Ich frage Tabellen ab, die unter 500.000 Datensätze haben - beziehe mich auf das Datum, welches im Jahr 2024 liegen soll.
    Normalerweise klicke ich auf nen Button, und das Ergebnis ist instant da - und das soll ein Problem sein?

    Ich glaube da gibt es ganz andere Datenmengen die hin- und hergeschoben werden, und die lösen nicht solche Probleme aus, oder was meint ihr?

    Unsere IT ist auch der Meinung, dass MS Access nicht in ein Unternehmen gehört. Nur denke ich, es gibt keinen einfacheren Weg Daten aufzubereiten und für Excel zur Verfügung zu stellen, oder?

    Rene M. schrieb:

    Unser Dienstleister ist nun der Meinung, dass meine Abfragen in Access soviel Traffic verursachen, dass mich die Azure DB aus Sicherheitsgründen für gewisse Zeit sperrt
    Wenn du dich nicht darauf verlassen willst, dann solltest du dir nachfragen wie man damit begründen kann, dass es erst seit einer Woche so ist.

    Rene M. schrieb:

    Unsere IT ist auch der Meinung, dass MS Access nicht in ein Unternehmen gehört.
    MS Access ist eine von vielen Datenbankmanagementsystemen, ich bin nicht sicher ab wann ein Unternehmen damit nicht zurecht kommt, halte die Aussage erstmal für stark pauschalisiert.

    Rene M. schrieb:

    Meine Frage: gibt es solche Sicherheits-Technik?
    Anscheinend schon Throttling
    Joa, klingt schon nach Throttling, hier noch mal direkt für Azure-SQL

    Leider ist die Ansage was du machst schon sehr high level. Vielleicht prüfst Du mal wie oft du Daten abrufst, wie viele Datensätze abgerufen werden und wie viel CPU, RAM und I/O deine Anfrage frisst.
    Es muss ja nicht an der reinen Anzahl der Datensätze, welche zu dir kommen, liegen. Wenn du viel Last erzeugst, kann das auch sein.
    Der IT-Dienstleister sollte in der Lage sein, dir nachzuweisen dass du zu viel Last erzeugt. Und wenn ja an welcher Stelle.

    Deiner IT würde ich sogar eher Recht geben. Access um dann Excel raus zu bekommen? Warum der Weg über Access? Und wenn es nach BI klingt, warum kein BI-Tool wie Power BI?
    Die deutsche Sprache ist Freeware, du kannst sie benutzen, ohne dafür zu bezahlen. Sie ist aber nicht Open Source, also darfst du sie nicht verändern, wie es dir gerade passt.

    Rene M. schrieb:


    Unsere IT ist auch der Meinung, dass MS Access nicht in ein Unternehmen gehört.

    Leider ist sowohl die Azure DB-Lösung als auch Access eine Strategie, bei der bei mir die Alarmglocken schrillen. Vor langer langer Zeit, als ich noch mit Access gearbeitet habe, da hatte ich das Problem, dass Access mit der Zeit immer größer + langsamer wurde. Kurzfristige Lösung dazu "
    Compact and repair a database" bei support.microsoft.com nachschlagen. Zu Azure stellt sich die Frage, ob du es gut (bzw. DSGV konform) findest, eingeschränkte Konntrolle über die Datenbank zu haben. Wenn der Dienstleister etwas behauptet, dann glaubst du ihm das oder nicht. Schön wäre, du hättest Zugrif auf logs usw. die diese Aussage stützen.