Habe seit längerem das selbe Problem mit einem Windows-Server. Erst teilweise bei Bildern die von Kunden und Mitarbeitern geschickt wurden, inzwischen auch Bilder von meinem eigenen Handy. Habe irgendwo gelesen, dass die Fotoanzeige nicht mit Metadaten klar kommt. Wir gehen nun teilweise hin und entfernen diese mit dem https://exiftool.org/. Anschließend lassen sich die Dateien ohne Probleme öffnen.
Zufrieden bin ich mit der Lösung aber auch nicht...

Laut Link und Link sollten Verzeichnisse ausgenommen werden können.

Auf ein paar unserer Maschinen wird vom Hersteller UWFUtility verwendet Link. Sämtliche Änderungen werden damit nach einem Neustart verworfen. Ist dann schon fast nervig, wenn tatsächlich was geändert werden muss.

Eher "Geschützte Systemdateien ausblenden" deaktivieren.

Danke, das wars 😃

Hallo zusammen,

habe für meinen Server ein RDX-Laufwerk zur Datensicherung eingerichtet. Die Festplatte wird auch beschrieben und Speicherplatz belegt, aber der Windows-Explorer zeigt keine Dateien auf dem Laufwerk an. Auch nicht wenn ich versteckte Dateien anzeigen lasse. Mich interessiert wie das gemacht wird. Denke mir fehlt das Stichwort für ne erfolgreiche Google-Suche.

Gruß

Das sollte das ganze eigentlich sichtbar machen.

excelDatei.Visible = true; 

Aber da du Excel am Schluss wieder schließt, kann es auch nicht lange offen/sichtbar bleiben.

Versuchs mal damit:
Rekursion mit Foreach

Was du mit einem Online Zugang meinst verstehe ich jetzt nicht genau.

Ich meine damit z.B. die Logindaten auf einer Website mit Nutzername und Kennwort.

Wenn du es auf einem Beschränken möchtest musst du noch ein wenig mehr Arbeit investieren und solltest auch daran denken, das es sein kann das ein Mitarbeiter sich nicht ausgeloggt hat.

Das ist und war bisher kein Problem, ist also erstmal nicht wichtig.

Kennwörter werden - wenn man selber die Autorität damit bestätigt - niemals im Klartext oder verschlüsselt hinterlegt.

Von so einem Kennwort merkt man sich nur den Hash-Wert, der durch den entsprechenden Salt immer unterschiedlich ist, auch wenn mehrere Benutzer das gleiche Kennwort verwenden.

Das trifft nur auf das Passwort zu, das den Schlüssel bereit stellt. Andernfalls könnte ich die Logindaten ja nicht wieder entschlüsseln. Oder hab ich da was falsch verstanden?

Im Prinzip geht es mir darum, ob es im Falle eines Angriffs einfacher wird Daten zu entschlüsseln, wenn diese mehrfach mit verschiedenen Schlüsseln abgespeichert wurden. Angenommen die Art der Verschlüsselung ist gut.

Hallo zusammen,

mich würde interessieren wie gut oder schlecht es ist, gleiche Passwörter/Daten mit verschiedenen Schlüsseln zu speichern.

Hintergrund ist folgender. In einem Betrieb besteht für verschiedene Lieferanten je nur ein Onlinezugang, den aber mehrere Mitarbeiter verwenden. In der "Passwortspeichersoftware" werden also mehrfach gleiche Passwörter für verschiedene Mitarbeiter mit verschiedenen Schlüsseln gespeichert.

Ich würde behaupten, da aus den verschlüsselten Daten nicht auf die Gleichheit der Daten zurückgeschlossen werden kann (oder doch?), dass dies nicht sonderlich sicherheitsrelevant ist.

Wie ist das wirklich?

Gruß

Laut BinaryReader.ReadByte-Methode fliegt am Ende eine EndofStreamException. Vielleicht so:

br.BaseStream.Position = 330;

try
{
     while(1)
     {
          Config += br.ReadByte().ToString();
     }
}
catch(EndofStreamException)
{

}

Keine Ahnung ob das sauber umgesetzt ist, sollte aber funktionieren.

Alternativ könnest du noch auf PeekChar prüfen. BinaryReader.PeekChar-Methode

Mal davon abgesehen das ich nicht weiß wie ^^

Ähh? Deine ComboBox heißt comboBox1? ->

RepeaterListeLaden(5, comboBox1);

hätte ich dann das Problem wenn ich aus der Funktion raus z.B. eine textBox befüllen will wieder und muss alles umschreiben, irgendwann habe ich dann 100 Parameter in dem Funktionsaufruf

Deshalb Schichten

Wie wärs denn damit: In der Methode lädst du lediglich die Items, gibst diese zurück und in der Form werden diese dann in der ComboBox aktualisiert.

Nach dem (3-)Schichten-Prinzip.

Groß-Kleinschreibweise beachten: ComboBox

Zum Thema static lässt sich in der MSDN folgendes finden : https://msdn.microsoft.com/de-de/library/79b3xss3.aspx

Deine Methode hat keinen Zugriff auf die Member deiner Form. Damit das ganze funktioniert, müsstes du die ComboBox mit an die ausgelagerte Methode übergeben, ala:

public void RepeaterListeLaden(int laden, ComboBox CB)
{
     ...
     CB.Items.Clear();
     ...
}

Es ist nicht viel Arbeit sowas zu speichern, das stimmt. Aber ändere mal was am Aufbau deiner Objekte. Nenne zum Beispiel ein Feld um. Tut die ganze Automatik dahinter dann wirklich immer noch was sie soll? Mach dich mit deiner DB auch mit Wartungsaufaben vertraut. Kannst du wirklich einfach (handlich) herausfinden was gerade alles in der DB steht? Kriegst du eine Übersicht aller Stammdaten durch ein Tool heraus wenns sein muss oder musst du dann dein Programm erweitern, Objekte laden und die visualisieren? "handlich" darf sich nicht nur aufs erste programmieren beziehen sondern sollte auch Fehlersuche und Erweiterungen einschließen.

In der Art wollte ich mich hier auch informieren, sollte in einem 2. Thread geschehen, werde aber vorerst nochmal auf eigene Faust probieren und nach Infomaterial suchen.
Ein Tool zum Auslesen der Daten gibt es.

Wenn das so ist ... bist du sicher dass die DB das so speichert? Dazu müsste sie erkennen dass sie genau dieses Objekt schon gespeichert hat und sie nur einen Verweis drauf anlegen muss.

Ja, hierauf legt die Doku ziemlich viel Wert drauf, das zu zeigen. Wie das intern gemacht wird weiß ich nicht, aber meine ersten Versuche bestätigen, dass es funktioniert.

Zur Aufgabenstellung:
Rahmenbedingungen sind: Ich möchte Positionen anlegen, die aus verschiedenen Profilen, mit vielen verschieden Variationsmöglichkeiten, aufgebaut sind. Alles andere ist frei gestaltbar.

Mein erster Denkansatz ist: Die Profile mit ihren Variationen werden zunächst in den sogenannten "Stamdaten" gespeichert. Aus diesen Stammdaten wird die Position in einer möglichen Variation der Profile aufgebaut. Objektdatenbank, um die Daten möglichst handlich zu haben, das Speicher- und Abrufprinzip hat mir sofort gefallen.

Du schreibst von einem Denkansatz wie du das in der DB ablegst und zeigst dann eine Klasse. Hängt das damit zusammen dass du eine Objektdatenbank hast, damit speicherst du dir die möglichen Breiten in einem Array eines einzigen Eintrags in dieser Tabelle?
Das würd ich nicht so machen. Stammdaten die nur aus Zahlen bestehen würde ich auch wirklich nur als Zahl speichern. Eine pro "Zeile".

Objektdatenbank heißt ja, dass ich komplette Instanzen einer Klasse speichere und auch so wieder abrufe. Intern, da hast du Recht, wäre das Array ein einziger Eintrag in der Tabelle der Datenbank, wobei das hier eigentlich in keinster Weise zum tragen kommt, denn wenn ich die Daten abrufe, werde ich nicht nur die möglichen Breiten benötigen. Insofern verstehe ich dich hier nicht.

Da es doch recht unterschiedliche Profile mit vielen Möglichkeiten gibt, spare ich mir so das Mapping der Felder.

Was bedeutet das?

In relationalen Datenbanken müsste ich zum speichern/abrufen Stringbefehle für jede Klasse erstellen(die Felder der Tabelle zuordnen/mappen), und die erhaltenen Daten aufdröseln und einer Klasse bzw. ihren Feldern zuordnen, was hier ein ziemlicher Aufwand wäre, wie ich finde. Dies würde bei der Objektdatenbank wegfallen.

Meinst du Klasse (eine eigene class die separat definiert ist) oder eine eigene Instanz einer gemeinsamen Klasse?

Angenommen ich würde jede mögliche Variation in einer eigenen Instanz einer Klasse in der Datenbank speichern, würde das für meinen Geschmack zu unüberschaubaren Datensätzen führen. Da sträube ich mich innerlich dagegen.

Wenn du eine Position anlegst würde ich da die Maße und sonstigen Angaben direkt reinschreiben.

Das habe ich mir auch überlegt. Das Problem, das ich darin sehe, ist die Übersichtlichkeit. Ohne die "Zwischenklasse" (hier: Rechteckprofil), müsste ich hier sehr viele Informationen in der Position unter bekommen. Mit Zwischenklassen wären die Daten mehr gekapselt (sagt man das so?). Grade im Hinblick darauf, dass die Daten der Profile teilweise stark übereinstimmen und teilweise klare Unterschiede haben, würde hier die Zuordnung wesentlich leichter fallen.

Bisher verstehe ich dich so, du hast eine Position die das Ergebnis einer Konfiguration ist.

Richtig.

In der gibts einen Verweis auf Rechteckprofil und darin wieder einen auf SdRechecktprofil. Das sind die Stammdaten nehme ich an?

Also SdRechteckprofil wären die Stammdaten, richtig.

Wozu braucht ein Rechteckprofil einen Verweis auf sämtliche (!) Möglichkeiten der Stammdaten? Dann hat jede Position einen Verweis auf sämtliche Möglichkeiten die zur Verfügung standen, das ist doch nicht nötig.

Angenommen ich bin in der Erfassung, wo Positionen angelegt und geändert werden, und beziehen uns nur mal auf das Ändern. Dann hätte ich mit einem Aufruf der Position alle Änderungsmöglichkeiten vorliegen und kann diese dem Bearbeiter anbieten. Den Vorteil sehe ich dabei in "mit einem Aufruf". Ich muss nicht erst 10 Anfragen an die Datenbank stellen, bis ich alle Daten habe, die ich benötige. Aber vielleicht hast du Recht, das muss ich mir nochmal durch den Kopf gehen lassen.

Platz spart es auch nicht wirklich.

Da nur ein Verweis und nicht eine Kopie der Stammdaten gespeichert wird, dürfte es nur einen sehr kleinen Teil ausmachen.

Die Klasse Position müsste dann auch wohl eher so aussehen(sagen wir mal für einen rechteckigen Rahmen, wobei später auch 5 oder mehr Ecken möglich sein sollen):

class Position
{
       object ProfilLinks;
       object ProfilOben;
       .....

       //Oder so
      object[] profile; //Beginnend links oder so
}

Hilft diese Erklärung? Bin mir grade nicht sicher ob es das hier schlimmer oder besser macht.

Hallo Zusammen,
ich bräuchte hier einen Rat zum Thema Datenstruktur/Datenbank-„Design“.
Zum Verständnis (vereinfacht): Ich habe eine Position (z.B. Holzrahmen) die aus verschiedenen Profilen (Rundprofil, Rechteckprofil) aufgebaut werden soll. Die Profile an sich können verschiedene Maße haben, also z.B. sind sie in einem Breitenraster 20, 25, 30, 35 mm verfügbar.

Mein Denkansatz, um sowas in einer Datenbank abzubilden, wäre: Die Profile werden zunächst mit den möglichen Maßen in den „Stammdaten“ hinterlegt:

class SdRechteckprofil
{
	Int[] Breitenmaße = {20, 25, 30, 35};
	// noch viele andere Maße und Eigenschafte (Farbe, usw. )
}

In einer Position können die Profile jedoch nicht mehr „variabel“ sein, sondern „fix“, da sonst die Position nicht eindeutig aufgebaut ist. Also hab ich mir folgendes überlegt:

class Rechteckprofil
{
	SdRechecktprofil SdRP;
	Int Breite; //Mit Set/Get wird geprüft, ob Breite möglich ist
}

Und dann natürlich Schlussendlich:

class Position
{
	Rechtecktprofil RP;
}

Die Datenbank ist eine Objektdatenbank. Da es doch recht unterschiedliche Profile mit vielen Möglichkeiten gibt, spare ich mir so das Mapping der Felder.
Überlegung des Ganzen:

• Ich brauche, während ich die Position bearbeite alle Informationen bis runter in die Datenbank. Rufe ich die Position in diesem Format einmal auf, habe ich sofort sämtliche Daten die ich benötige.
• Da ich nicht einfach in jede Position die benötigten Profile der Stammdaten kopiere, spare ich Speicherplatz. (wobei das vermutlich standartmäßig so gemacht wird, hier fehlt mir die Erfahrung)
• Änderungen an den Stammdaten werden sofort in die Profile/Positionen übernommen.
• Nicht jede Variation der Profile kann eine eigene Klasse bekommen, dafür gibt es viel zu viele Kombinationsmöglichkeiten.

Was haltet ihr von diesem System, was wäre eure Lösung?
Muss dazu sagen, dass ich noch sehr sehr wenig mit Datenbanken zu tun hatte.

Mit freundlichen Grüßen

Edit: Rechtschreibung