Weingeist

Hallo Leute, Beim Durchstöbern von https://docs.microsoft.com/en-us/windows-server/storage/storage-replica/storage-replica-overview Bin ich auf folgende Aussage gestossen: "Storage Replica also has a server-to-self mode, where you point replication to two different volumes on the same computer." - Muss es bei einem Reboot oder Kaltstart wieder angeschubst werden oder geschieht das automatisch? (Egal ob gleicher Server oder zwei verschiedene) - Ist das Server-Intern crashresistent? Sprich passiert auf File-System-Ebene nicht viel wenn z.B. der Stecker gezogen wird? (metaphorisch gemeint, kann ja auch BlueScreen oder sowas sein) - Server-Intern auch nur ein Datacenter-Feature? Vermute DC - Funktioniert das auch mit Dedupe-Volumes zuverlässig? Wird Dedupe beibehalten oder ist es ein Feature des Ziels? Eigentlich müsste es das ja, wenn alles Blocklevel-basiert ist - Werden File-System Fehler mitkopiert oder ist das gänzlich unabhängig? Da Blocklevel, schätze ich mitkopiert. Wäre vielleicht eine gute Ablösung für diverse Robocopy Mirror's die ich gerne als schnell verfügbare Desaster-Kopie von Fileservern in Umgebungen mit eher kleinem Budget vorhalte. Auch ein RAID-Rebuild mit grossen, lahmen Festplatten wäre dann keine Zitterpartie mehr weil man immer eine Topaktuelle Kopie in petto hat und nicht eine von letzter Nacht. Wenn das sogar für laufende VM's mit VSS tauglich ist, auch recht nett (zumindest solange die Applikationen nichts gegen Kaltstarts haben oder die Applikation eben VSS unterstützt.). Insgesamt - sofern ich das richtig interpretiert habe - mal ein richtig guter Upgrade-Grund von 2012R2 auf 2016. Auch in einer Kleinumgebung. :) Grüsse und vielen Dank

@Sunny61: Stimmt, WID ist wohl - seit geraumer Zeit - eine gute Alternative. Danke für den Hinweis. Bezüglich der Pipe: Die richtige Syntax für die Verbindung zur Pipe steht trotzdem im Konfigurationsmanager. Wenn da ein $ Zeichen in der Pipe steht - aus welchem Grund auch immer und sei es nur weil es jemand geändert hat -, dann braucht es für die Verbinung auch ein $ Zeichen und nicht den Backslash. Korrekt ist aber sicher - habe ich nun auch mit einer etwas neueren Installation als meiner eigenen nachgeprüft - das es standardmässig so lautet wie Du es gesagt hast und demzufolge auch so bleiben sollte.

WID steht doch normal für die Windows Internal Database, also den kastrierten SQL-Server oder was auch immer für ein Gebilde das heute ist. Setze den schon ewig nicht mehr ein und habe deshalb auch keinerlei Erfahrung mit Ihr. Für einen richtigen SQL - auch wenn es express ist - müsste eigentlich nach wie vor meine Syntax richtig sein. Im Endeffekt ist jeweils das korrekt, was im Konfigurationsmanager unter Pipe tatsächlich eingetragen ist. Zu Anzahl Verbindungen: Soweit ich mir das mal notiert habe, war das trotzdem möglich wenn die Anz. Verbindungen erschöpft waren und viele Clients gleichzeitig abgeglichen habe. Dann hatte ich in der Vergangenheit auch schon Aussetzer wegen den Verbindungslimits. Soweit ich mich erinnere auch in der Konsole.

Hatte das Problem schon mit den verschiedensten Screens, Hardware etc. beobachten können. Windows muss ned mal zwingend im Standby sein, es reicht, wenn nur der Bildschirm durch das OS ausgeschaltet wird. Fast schon konsequent tritt es auf wenn man mit Extendern arbeitest. Allerdings geht meine Vermutung in eine andere Richtung als zum Bildschirm selbst. Ich konnte des öfteren beobachten, dass wenn ich USB-Geräte getrennt oder abgestöpselt habe oder deren Stromzufuhr gekappt wurde (Barcode-Reader, Handy-Ladegerät etc.), das Problem so halb zuverlässig provoziert wurde. Ende vom Lied ist dann, dass der Mausklick oder der Tastatur-Schlag welcher den Bildschirm wieder anschaltet oder den PC weckt, gar nicht erst bei Windows ankommt. Bei virtuellen Desktop oder der Arbeit mit Extendern schalte ich deshalb sämtliche Energiespareinstellungen für Bildschirm und USB ab. Seither habe ich Ruhe. Das es vermehrt mit Display-Port auftritt, könnte daran liegen, dass der AUX-Kanal des Displayports gerne mit USB beschaltet wird/wurde. Gibt es da Ärger mit den Energiespareinstellungen, hat man den Salat. Beheben kannst es zum Beispiel, wenn Du alles an Energiespareinstellungen des Bildschirms und vor allem der ganzen USB-Geräte seitens des OS abdrehst. Manchmal helfen auch Firmware und Treiberupdate. Einen PC mit schwarzem Bildschirm kanns übrigens relativ einfach "aktivieren" indem Du Dich von einem anderen PC per RDP auf den PC mit dem schwarzen Screen verbindest. Schwupps, geht es wieder =)

Klar kannst das ganze irgendwie scripten. Ich würde es aber trotzdem nicht automatisch sondern nur im Desaster-Fall per Hand auslösen. "Normale" Unterbrüche werden ja sowieso abgefangen weil die eigentlichen Fileserver selber wieder auf ner anderen physischen Maschine anstarten sofern das gewünscht ist. Mit DFS-R hast dagegen schnell die Verfügbarkeit der Daten verkleinert anstelle vergrössert, wenn die Targets selbständig hin und herswitchen. Sei es nur weil Du einen Server rebootest. Gibt unter Umständen sehr lästige Effekte wo manuell eingegriffen werden muss oder nach Murphy automatisch das falsche gewählt wird. Die Kiste bzw. das Storage dahinter darf dann auch gerne etwas langsamer sein wenn nicht mordsmässig viele Daten parallel verarbeitet werden sondern einfach die Datenmenge gross ist. Wenn der Fall wirklich eintritt, dass der ganze Fileserver komplett platt ist, obwohl gut gesichert, ist man froh überhaupt schnell wieder was aktuelles zu haben und die Zeit in den rest der VM's zu investieren und ganz zum Schluss den Fileserver wieder in hochzuziehen. Backup-Storage hat damit eh schon genug zu tun. Aber das ist nur meine persönliche Meinung basiert auf Erfahrungen in Kleinumgebungen. Mag jeder wieder anders sehen.

Ein paar Tipps am Rande noch, damit Du später nicht auf die Schnautze fällst. DFS kann für Anfänger recht fies sein, meist mit Verzögerung. =) 1. DFS sollte nicht auf dem DC installiert werden, bzw. nicht auf jenem mit der PDC-FSMO-Rolle. Am besten sollte die physische Maschine eine andere sein damit nicht (auch wens eine VM ist). Wenn der der PDC ausfällt, änderst Du nichts mehr an Deinem DFS-Root. Du kannst also nicht auf ein anderes Ziel umschalten. Fällt also der Haupt-DFS zusammen mit dem PDC aus, ist Ruhe im Karton wenn der DC auch der Fileserver mit den aktiven Targets ist. 2. DFS-R würde ich persönlich nicht auf zwei aktive Targets verwenden sondern nur ein Target für die Usere aktivieren und das zweite z.B. deaktivieren. Dann hast bereits 99% der Ärgernisse mit DFS-R von vornherein nicht. Es arbeiten dann alle auf dem ersten Target. Im Fehlerfall kannst dann einfach umschalten auf das zweite. Ich mache das gerne als schnell verfügbares Zweitsystem für den Fileserver, weil der in der Regel ne weile braucht für ein recovery. Das umschalten auf ein anderes Target (also aktivieren/deaktivieren) geht aber nur, wenn der PDC zu diesem Zeitpunkt noch lebt. Deshalb eben auch möglichst physisch trennen. 3. Dann auch immer DFS-R separat und nicht mit dem Wizard konfigurieren. Dann kann man es unabhängig voneinander ändern und löschen. Anbei noch ein lesenswerter Artikel (wenn auch etwas älter) https://blogs.technet.microsoft.com/deds/2011/07/12/wie-ein-dfs-namespace-nicht-aussehen-sollte/ https://blogs.technet.microsoft.com/askds/2012/07/24/common-dfsn-configuration-mistakes-and-oversights/

Müsste eigentlich auch gehen, wenn Du die lokale Sicherheitsrichtlinie anpassen tust. Der User brauch ein Anmeldungsrecht, gut möglich, dass er das aufgrund der lokalen Sicherheitsrichtlinie nicht hat und die Verbindung deshalb verweigert wird. --> Lokale Sicherheitsrichtlinie>zuweisen von benutzerrechten>Anmelden mit Remotedesktop / lokale Anmeldung zulassen sind die beiden relevanten Einstellungen welche ein über die übliche Maske gegebenes Recht trotzdem abwürgen kann. Solange es ein Admin ist, der sich drauf verbindet, ist das kein Lizenzverstoss. Wenn das nur einer aufs mal ist, brauchst normal auch keine Rolle. Habe es ehrlich gesagt aber schon länger nicht mehr gebraucht. Daher nicht zu 100% sicher!

Normal hat das Verbindungs-Problem eher einen SQL-Server als einen WSUS Hintergrund. Ist ned mal so besonders von der Anzahl Clients sondern eher Anzahl Plattformen / Produkte die man hat abhängig. RAM soll er sich normal nehmen was er kriegt. =) Abschalten lässt es sich in der Regel wenn man in den Verbindungseinstellungen das Verbindungslimit maximiert. Also auf unlimitiert, auch das Timeout (insbesondere das). Ich meine du musst dich per Pipe verbinden damit Du den Reiter siehst. Dazu musst Du im Konfigurationsmanager des SQL-Servers NamedPipes aktiviert haben. Verbindungspfad: \\.\pipe\MSSQL$WSUS\sql\query (WSUS durch Instanzname ersetzen) Du verbindest Dich also mit dem Management Studio auf den WSUS, Rechte Maustaste Servereigenschaften (im obersten Element des tree's), Register Verbindungen, maximale Anzahl Verbindungen entweder auf 0 oder deutlich erhöhen, Remoteverbindungen zulassen, TimeOut=0. Dann laufen auch Wartungsscripts sowie interne Serverbereinigungs-Tasks sauber durch. Wartungsscript würde ich übrigens auch immer empfehlen als Windows-Task einzurichten (siehe www.wsus.de)

Na da würde ich nicht lange rumeiern und pröbeln! Festplatte ausbauen, externen HDD-Rahmen kaufen und per USB an einen anderen Rechner anschliessen und alles was man noch möchte rüberkopieren. Das macht man eigentlich spätestens nach den ersten paar Fehlschlägen. Dann neue SSD kaufen und neu installieren. Insgesamt kann man aber sagen, dass die Chancen bei SSD's frappant kleiner sind etwas brauchbares zu erhalten als bei Magnetplatten. Da du noch Fehlermeldungen vom OS zu bekommen scheinst, ist es aber möglich, dass nicht die ganze Zuordnungstabelle geschrottet ist. Wens aufwendiger sein soll weil mehr Daten gebraucht werden: Sector-To-Sector Kopie der HDD anlegen, dann dieses Kopie kopieren anschliessend mit einer der Kopien rumpröbeln für die Datenrettung. Das Original auf die Seite für eine allfällige inanspruchnahme von externe Hilfe. Tools für Recovery z.B.: GetDataBack for NTFS, Ontrack Easy Recovery. Meistens klappts mit einem der beiden wenn noch etwas brauchbares rum ist.

Habe das grad gelese weil ich das auch haben möchte. Danke für die Infos! Ich würde vor der Verwendung von externen Tools immer die Bordmittel nehmen wenn diese das hergeben. Auch wenn es etwas aufwendiger in der Bedienung ist. Ist auch eine Frage der Sicherheit.

Du könntest es Dir schon etwas einfacher machen. Du bräuchtest einfach einen Open-License/Open Value Vertrag mit MS und könntest LTSB installieren. Ich mache nach Möglichkeit nix anderes mehr. Da kriegst Du dann nur noch Sicherheitsupdates und keine kompletten Builds. Auf Edge musst Du aktuell halt verzichten, empfinde ich persönlich aber eher positiv als negativ =)

Es gab mal von MS ne schicke Anleitung wie man bei Windows Update Fehlern vorzugehen hat. Leider is die durch ein Self-Diagnosis-Tool ersetzt worden. Im grossen und ganzen kann man sagen, dass SoftwareDistribution oft nur die halbe Miete ist. In der Regel sollte folgender Ordner auch gekillt oder umbenannt werden: %systemroot%\system32\catroot2 Es gab noch mehr, das kann ich aber nicht mehr auffinden. Leider. Beides mit gestopptem Bits / wuauserv Auch der UpdateClient sollte aktuell sein Danch ein Neustart. Ansonsten habe ich die Erfahrung gemacht, dass sich gerade die Chefs nicht unbedingt an die "Regeln" bezüglich surfen halte und sie die ersten sind, die sich was einfangen =)

Ob es bei Home auch funktioniert, keine Ahnung. Aber in den Business Versionen kannst den Updatedienst ja per GPO konfigurieren. Notfalls per lokaler gpo mit gpedit.msc Wenn Du nun bei allen Adressen (3 an der Zahl) einen imaginären WSUS einträgst und die Suche von Updates über Internet verbietest, dann geht da nix mehr. Zusätzlich kann man noch ein paar explizite Block-Regeln in der Firewall für ausgehenden Verkehr erstellen, dann ist auch Ruhe im Karton. Die würde ich eh per Whitelisting konfigurieren wenn die Updates ausbleiben, ob das aber praktikabel ist für Privatrechner, sei mal dahingestellt. Bis jetzt war es das einzige was wirklich Nachhaltig war. Dienst und Task werden immer irgendwie wieder aktiviert. Mich stört diese erzwungene Updaterei auch. Zumindest das man nicht wie früher einzelne KB's nehmen konnte also nur Sicherheitsupdates/Wichtige Updates und Feature-Kram aussen vor lassen. Ich würde Deiner Bekannten sagen, dass Du es Ihr nur mit einer LTSB deaktivieren kannst und sie diese Version braucht. Dann gibts nach wie vor alle Sicherheits-Updates. Weiss nur ned ob man als Privatperson überhaupt da ran kommt. Auch die Wilde Datensammlerei sowie Übertragerei lässt sich etwas besser eindämmen was bei Home fast unmöglich sinnvoll umzusetzen ist.

Ist das zufällig eine sehr seltsame statische IP? Also nix zu tun mit Deinem lokalen Netzwerk? Dell-Maschine? Habe dieses Problem auch bei einer Maschine. Da hilft jeweils Aktivieren/Deaktivieren der Netzwerkkarte, dann holt er sich die korrekte Adresse. Muss hier nach jedem neustart gemacht werden. Super nervig. Eine zusätzliche Netzwerkkarte hat auch nix geholfen. Vielleicht gibt es ja seitens des Herstellers ein BIOS Update, Netzwerkkarten-Firmware Update oder dergleichen. Bei mir hat alels nix geholfen. Als Übeltäter tippe ich auf UEFI, ein Management-Interface des Server-Herstellers das auf den normalen Port geroutet wird, Intel AMT oder eine Kombination davon welcher die zugewiesene IP nicht wieder rauslöscht. Kann ja alles möglich ausgeführt werden in diesen Pre-OS Bootsystemen. Theoretisch wäre auch eine Malware möglich die sich auf dieser Ebene eingeschlichen hat.

Deaktivieren ist nicht so einfach. Die meisten Einstellungen macht Windows selbständig mittels Tasks/Services wieder rückgängig. Ich bin aber auch grundsätzlich der Ansicht von Testperson, dass man zuerst mal die Probleme angehen sollte. Am meisten Ruhe hast mit der LTSB-Version. Da gibt es (fast) nur Sicherheitsupdates. Wie auch immer, es gibt auch Situationen wo man dazu gezwungen wird. Bei Industrie-Steuerungen sehe ich mich in die frühe XP Zeit zurückversetzt wo selbst Sicherheitsupdates auf Steuerungen nicht möglich waren ohne die Kisten abzuschiessen. Da eigentlich nur LTSB für die Industrie tauglich ist, diese aber so gut wie nie eingesetzt wird, kann man wieder munter Update-Dienste komplett abdrehen. Dabei war es die letzten 10 Jahre so schön. Habe so gut wie nie mehr Ärger gehabt mit Updates und heute legt es mir ganze Produktionszellen lahm. Zu deiner Frage: - In der GPO (lokal oder auf AD) eine fiktive WSUS-Adresse eintragen (3 Einstellungen) - Internetkonnektivitäts-Erlaubnis für Update-Dienst abdrehen (GPO) - Möglickeit entziehen, online nach Updates zu suchen (GPO) Dann ist Ruhe im Karton auch wenn W10 die Dienste selbständig wieder aktiviert. Auch restriktive Firewall-Regeln bzw. Whitelisting hilft, dazu sind aber Eingriffe in die Registry nötig (manuelle Bearbeitung von System-Regeln).

Hi Dr. Es wäre schön wenn Du mit genauso viel Elan diese Aussage in der Versenkung verschwinden lassen würdet, wie Du gegen jeden Kommentare vorgehst, der gegen die aktuelle MS-Politik spricht. Sie ist nämlich schlicht falsch. MS hat nach wie vor ein Quasi-Monopol im KMU-Bereich. Man hat nur eine Pseudo-Wahl an MS vorbeizukommen. Das weisst auch Du ganz genau. Erkenne das bitte auch endlich mal an. Und das die Regeln egal ob Preis-, Lizenz- oder Datenschutztechnischer Natur vor nicht allzulanger Zeit noch deutlich besser für den Kunden waren, ist nunmal ebenso Fakt. Da musst Du dich genauso damit abfinden, wie sich die Leute mit Deinen Aussagen zu diesem Thema abfinden müssen. Ändert natürlich nichts daran, dass sich der TO ebenfalls mit den Regeln abfinden muss. Ob er nun will oder nicht. Eine Wahl wird er wie viele andere auch - objektiv gesehen - nicht haben.

Kurze Rückmeldung (ist ja so dolles Wetter, kann man auch ohne Verlust arbeiten *g*) - mit der zusätzlichen Tabelle klappt es 1A. 1. Tabelle erstellt mit je einem Feld für jeden Datentyp 2. Qry erstellen die gleich aufgebaut ist (Feldnamen, Datentyp) wie die anderen (SELECT tbl0.valGUID AS Feld1_GUID, tbl0.valGUID AS Feld2_GUID tbl0.valCurrency AS Feld3 FROM tbl0) 3. die neue Qry an erster Stelle mit in die UNION SELECT aufnehmen Die Performance ist wie vermutet identisch. Bei nachfolgendem Joins mit Basis der Union-Qry vielleicht sogar ein tick schneller. Die tbl0 verwendete ich vorher schon für Berichte als Datengrundlage. (Access hat bei der Arbeit mit Instanzen und Manipulation am Design/Datengrundlage teilweise die Angewohnheit die Daten doppelt zu laden. Basiert die Datengrundlage auf einer Tabelle ohne Datensätze geht das öffnen von Reports nahezu doppelt so schnell.)

@Zahni: Access nur für Backend: Naja, da hast sicher nicht unrecht. Aber gerade die Backend wäre eigentlich sinnvoll von Anfang an auf SQL. Ist halt ein typisches Access-Projekt, mit was kleinem Angefangen und ständig gewachsen. Sind an die 350 Tabellen und rund 150'000 Zeilen Code (alles objektorientiert, wenig doppeltes). Eine Migration wäre aufgrund vieler automatisierten Workflows mit Barcode-Reader, Waagen usw. extrem aufwändig. Dafür ist die Syntax seit nunmehr 20 Jahren identisch da VB6 und läuft (noch) einfach auf jeder Kiste. Bei .Net wären die laufenden Anpassungen viel Aufwendiger ;) @Frank: Jetzt hast dus! Hätte noch mehr auf Lager die man normalerweise nie zu Gesicht bekommt. Bis hin zur untersten Ebene mit C++ runtime Fehler wo das ganze Office abschmiert. Yep, das mit der Reihenfolge hatte ich auch rausgefunden, hilft aber nicht wenn Du deren zwei Qry's hast die jeweils ein einzigartiges Feld haben. Ein halbpatzige Lösungen habe ich, ist aber irgendwie nicht dauerhaft 1. die Abfrage mit einer ge-0-tenGUID speichern (ein allfälliges bereits existierendes Feld mit NULL das Kauderwelsch verursacht muss erst gelöscht und Abfrage gespeichert werden). 2. die 0er-GUID mit NULL ersetzen und wieder speichern Leider habe ich keine Ahnung wo Access die ganzen Quellcodes mit allen Angaben von Abfrage/Formularen/Klassen ablegt damit man es selber reinpatchen könnte. Läuft über irgendwelche XML-Schnittstellen, habe dazu aber leider noch keine Doku gefunden gefunden wie man das selber nutzen könnte. Habe da schon Stunden mit Analysen verbracht. Dann halt die Workarounds die ich teilweise schon genannt habe: 1. In den anderen Tabellen ein Phantomfeld (gefällt mir gar nicht) 2. Eine zusätzliche Tabelle nennen wir sie mal "tbl0union" mit jeweils einem Feld jedes Datentyps und dann mit dieser eine zusätzliche Abfrage erstellen, die man dann zuoberste in die UNION-QRY packt. Dürfte auf die Performance keine Auswirkungen oder höchstens eine positive haben, weil eine Tabelle ohne Datensätze den Feldtyp für sämtliche Felder erzwingt. Sprich keine der Folgeabfragen hat dann ein udefiniertes NULL-Feld mehr. Oder direkt mit Aliasen in die UNION-Qry ist dann aber weniger übersichtlich. (Die gefällt mir eigentlich gar nicht so schlecht, ist mir gestern Abend beim Bier als Gedankenblitz durch den Kopf) Bezüglich CAST: Der heisst in Access StringFromGUID und gibt die 36er Variante raus. Für SQL Qry's brauchst z.B. die 45er Variante und in der Software der Einfachheit halber die 32er oder 36er. Habe ich mit einer eigenen StringFromGUID gelöst wo ich die Länge als Argument übergeben kann. Die Arbeit mit GUID's ist eigentlich ziemlich easy. Sie vereinfachen sogar so manches. Solange man eben die Cave-Eats kennt und zu umgehen weiss. Richtig lästig ist nur das keine Verknüpfungen von Main und Subreports direkt möglich sind und eben die gecastete Variante in der zugrundeliegenden Abfrage notwendig ist. Solange man das aber in der letzten Qry macht, ist die Performance gut.

@Zahni: Ja klar, aber wenn ich nachher die UNION Qry wieder joinen muss ist eben essig. Könnte ich natürlich auch in den Zugrundeliegenden Abfragen bereits erledigen, ist aber deutlich langsamer (knapp 30%) als wenn ich erst auf Basis der UNION-Qry einen Join laufen lasse und auch die Komplexität/Wartung der zugrundeliegenden Abfragen sowie die Übersicht wird um ein vielfaches mühsamer. Warum GUID: Die ganze Anwendung basiert mehrheitlich auf GUID's. Hat verschiedene Gründe warum das im Endeffekt deutlich besser ist. Insbesondere dient es der wirkungsvollen Datenkonflikt-Vermeidung wenn viele Clients auf die gleiche Backend-Zugreifen. Man hat ja keine SP's in Access und muss alles in der Software abbilden. Die meisten Probleme die man mit Multi-User und Access haben kann, treten mit GUID's als Keys in Bearbeitungstabellen gar nicht erst auf. Auch kann man die Write-Zeiten auf ein Minimum reduzieren weil Datensätze inkl. PK's erstmal nur im RAM der Clients liegen und dann gesammelt geschrieben werden = Weniger gleichzeitige Writes = Vielfaches der Performance und keine Daten-Konflikte. Ein weiterer Punkt sind externe Daten. Die können generiert und ohne Anpassung exportier/importiert werden. Ein Abgleich ist mit GUID's als PK/FK ist viel einfacher als mit einfachen Zahlen. Einfache Zahlen kann eigentlich nur ein Server zuverlässig generieren, eine GUID auch problemlos ein Client. @Der Frank: Solange die zugrundeliegende Tabelle ein GUID-Feld hat, welches wiederum in manchen Datensätzen den Wert NULL und in manchen Datensätzen einen ForeignKey auf eine andere Tabelle aufweist, ist alles kein Problem. Wenn aber eine der Queries dieses Feld nicht in einer Tabelle hat, wird es zum Problem. Siehe dazu die SQL-Syntax der Abfragen meiner letzten Antwort. --> (SQL-Syntax: Feld2 AS NULL)

Die richtigen GUID's müsste ich dann auch umwandeln damit es so überhaupt klappt. Wenn aber GUID's in CHAR umgewandelt werden, wird die Performance unterirdisch wenn nachher noch ein Join gemacht werden muss. Kann man komplett knicken. Muss ich an manchen Stellen zwar auch machen, aber nur wenn ein Formular oder Report die GUID nicht selber wandeln kann und das ist nur bei der Verlinkung mit SubReports/Forms der Fall. Dann gibt es das aber immer als zusätzliches Feld und nicht anstatt. Eine ge-0-te GUID ( {guid {00000000-0000-0000-0000-000000000000}} ) funktioniert übrigens. Dann sind aber allfällige Joins auf eine grössere UNION SELECT Qry wieder sehr viel langsamer als wenn es wirklich NULL Werte sind. Diese werden bei JOINS ignoriert. Die realen Abfragen sind leider bei weitem nicht so trivial gestrickt wie mein Reproduzier-Muster hier.

Ja klar, Aliase sind ja SQL Basics. Die Syntax von Access (ADO) ist ja eh identisch mit SQL-Server. Wenn das Probleme geben würde, hätte ich mit dem Stück Software ganz andere Probleme. Das Problem gibt es auch nur mit GUID's. Mit alle anderen Datentypen habe ich diese Probleme nicht. Wenn noch jemand eine Idee hätte wäre das Klasse, ansonsten läuft es dann halt auf ein leeres PhantomFeld hinaus, was ich eigentlich vermeiden wollte.

Hi, solange es separate Queries sind, ist das 0 Problem. Kann und darf keines sein. Nur innerhalb der UNION muss man mit den Alias logischerweise unterscheiden. Oder wenn mit Unterabfragen innerhalb der gleichen SQL-Qry gearbeitet wird. Gleiche Alias wird nur zum Problem wenn man innerhalb der Ursprungs-Qry mehrere Feldnamen mit dem gleichen Namen aus unterschiedlichen Tabellen hat, dann macht der Compiler Alias.Feld draus. Dann gibt es Probleme wenn man das Alias in der nächsten Abfrage wieder verwendet.

Danke für den Input. Es ist eine AccessDB in SQL-Server Format (Also ADO als Standard). Ob es beim SQL-Server genauso gehandhabt wird, habe ich ehrlich gesagt gar nicht nachgeprüft. Grade bemerkt, dass ich in SQL-Server gepostet habe. Im Grunde ist es ganz einfach, versuche es mal in anderen Worten: 1. In Abfrage 1 kommt in Feld 2 eine GUID oder NULL 2. In Abfrage 2 gibt es dieses Feld nicht und wird auch nicht gebraucht, Ich kann also kein Tabellenfeld als Feld 2 definieren sondern definiere das Feld direkt (berechnet). Syntax Abfrage 1 wäre: "SELECT A.Feld1, A.Feld2 From Tabelle1 AS A" Syntax Abfrage 2 wäre: "SELECT A.Feld1, NULL AS Feld2 FROM Tabelle2 AS A" Dann UNION SELECT über diese beiden Abfragen. Also (Bewusst zuerst die Abfrage 2, da er da eher auf die Schnautze fällt) SELECT * FROM Abfrage2 UNION ALL SELECT * FROM Abfrage1 Seltsamerweise hat es auch schon funktioniert. Scheinbar interpretiert er aber in diesem Fall nicht immer identisch oder aber es wird irgendwo ein Feldtyp gespeichert, den man aber nicht ändern kann.

Hallo Leute, Gibt es eine Möglichkeit einem berechneten/neuen Feld in einer Qry den Wert NULL eines bestimmten FieldTypes zuzuweisen? Insbesondere GUID? Ausgangslage: Abfrage 1: Feld 1: GUID als Autowert Feld 2: GUID als FK auf Tabelle 2 (also NullWerte oder eben ein ForeignKey auf eine andere Tabelle) Feld X: Diverse Felder Abfrage 2: Feld 1: GUID als AutoWert Feld 2: NULL (Kein zugehöriges Tabellenfeld) Feld X: Diverse Felder Lege ich nun eine UNION-SELECT über diese beiden bzw. mehrere Abfragen mit gleichem Stil, dann werden die "richtigen" GUID's des Feldes 2 aus Abfrage1 in Kauderwelsch, also Sonderzeichen, chinesische Zeichen usw. umgewandelt. Ich vermute, dass die Null-Werte von Feld 2 der anderen Abfragen nicht als NULL-Werte von GUID's interpriert werden sondern als Binary oder sonstwas. Dies Obwohl die einzig vorhandenen Werte in Feld 2 - die nicht NULL sind - aus den verschiedenen Abfragen ausschliesslich GUIDs sind. Wie kann man nun Feld 2 in Abfrage 2 verklickern, dass es eben eine GUID mit Wert NULL ist? Einen Work-Around gibt es, indem ich einfach in der Datengrundlage von Abfrage2 in einer Tabelle ein GUID Feld ohne Funktion erzeuge. Wenn es anders geht, fände ich das aber schöner. Grüsse und Danke

Hi, dürfte am nicht gestarteten oder nicht erreichbaren Dienst Remoteregistrierung auf dem Server liegen (net start RemoteRegistry). Sollte er gestartet sein, Firewall-Regeln prüfen. Zum Beispiel indem das Auditing eingeschaltet wird: In CMD: auditpol.exe /set /category:"Objektzugriff" /subcategory:"Filterplattform: verworfene Pakete" /success:disable /failure:enable Danach Ereignisviewer Sicherheit aufrufen, dann siehst alle verworfenen Pakete mit Protokoll, Port sowie die Prozess-ID welche es verursacht hat. Mit Tasklist /svc findest die entsprechenden Dienste raus die zum Prozess gehören. Dann kannst für diese entsprechende Regeln erstellen. Insbesondere Hilfreich wenn das Standardverhalten von Outgoing Allow auf Outgoing Block gestellt wird (was eigentlich immer gemacht werden sollte).