klaus_b

Auf den Punkt gebracht: Es spielt keine Rolle welche Konstellation von Back-End und Thin-Client du verwendest. Du bist immer zu langsam. Läut die Anwendung auf dem Back-End und du bekommst nur die Visualisierung auf den Thin-Client ist die Response-Zeit, bedingt durch die Latenz der Verbindung, so im Keller, dass du nicht wirklich Produktiv arbeiten kannst. Läuft die Anwendung auf dem Thin-Client, must du den CLient so hochrüsten, dass es kein Thin-Client per Definition mehr ist. Ja, es muss jedes Pixel einzeln übertragen werden. Ein CAD-System ist keine Visualisierungs-Anwendung, sonder ein hoch interaktives System welches auf jede Aktion des Benutzers sofort reagiert. Hinter jedem Pixel verbergen sich, je nach aktuellem Zoom-Faktor, eine Unmenge von Informationen. Oder wie kann man sonst Elemente manipulieren, deren Disztanz sich beispielsweise im sechsten Nachkommabereich eines Milimeters bewegt? Wenn du diese Anforderungen über eine Netzwerkleitung erfüllen kannst, ohne dabei jedesmal eine Kaffeepause zwischen zwei Aktionen zu erzwingen, spricht nichts gegen die Verwendung einer Server-Client Lösung. Servus, Klaus

Ich bin mir sicher, dass diese "Projekte" reine Verkaufspräsentationen sind :) Nicht wirklich. Der Hersteller der Grafikchips spielt mittlerweile nur noch eine untergeordnete Rolle, da die komplette Visualisierung für fast alle Elemente über OpenGL realisiert wird. Egal ob Linien, Flächen oder Körper. Selbst die Gummiband-Technik bei interaktiver Modellierung wird heute via OpenGL umgesetzt. 256 Mb Grafikspeicher sind ein Witz. 1Gb sollte auf alle Fälle vorhanden sein. Und RAM soviel wie das OS her gibt. Auch die HDs sollten so schnell als Möglich sein. SCSI Ultra 320 ist fast schon Pflicht. Für die CAD-Daten unbedingt eine eigene physikalische Platte verbauen. Unterschätzt die HD-Zugriffe während einer CAD-Session nicht. Ihr dürft euch bei der Arbeit mit CAD-Systemen nicht die Bearbeitung eines einzelnen Bauteils vorstellen, sondern die Bearbeitung ganzer Baugruppen mit zum Teil 5000 und mehr Einzelteilen. Das sind gewaltige Datenmengen, bei denen selbst SCSI Subsysteme beim laden und speichern der Modelle Wartezeiten von 30 sec. bis mehrere Minuten verursachen. Bei der Arbeit mit Baugruppen, werden die einzelnen Bauteile nur visualisiert. Erste wenn eine einzelnen Bauteil zur Bearbeitung selektiert wird, wird dieses real geladen. Wird ein anderes Bauteil ebenfalls zum bearbeiten selektiert, muss diese auch geladen werden. Reicht der RAM nicht, wird geswappt. Oft werden mehrere Modelle parallel in der selben Instanz geöffnet. Beim Wechsel zwischen den verschiedenen Modellen muss das jeweilige als aktiv markiert und in den RAM geladen werden. Wenn ihr die Möglichkeit habt, lasst währen einer CAD-Session den Performance Monitor eine Aufzeichnung von CPU-Last, IO-Zugriffe, RAM-Auslastung und der Pagefile-Auslastung durchführen. Dann werdet ihr schnell sehen, wo der Flaschenhals sitzt. Ich habe die gleiche Diskussion schon öfter mit System ITlern geführt. Erst wenn man ihnen den direkten Vergleich einer "fetten" WS und eines Thin-Client zeigt, haben sie es verstanden. Servus, Klaus

Hallo Thomas, vergiss irgendeine Lösung die nicht auf einer eigenen Workstation beruht. Du kannst gerade CAD und CAM System mit kaum anderen Anwendungen vergleichen. Wenn du ein CAD-System remote anbietest, macht dir das kein Konstrukteur mit. Ich weiß wovon ich rede :) Die Problematik bei CAD-Anwendungen ist die schnelle pixelgenaue Interaktion der Anwendung mit dem Benutzer. Es ist nicht nur so, das du durch die interaktive Modellierung im Raum ein sehr hohes Datenaufkommen zwischen RAM und der Grafik hast, sondern dass jedes sichtbare Element auf dem Bildschirm einen eigenen Kontext bildet. Soll heissen: Wenn der Benutzer die Maus über eine Linie bewegt, bildet die Anwendung einen anderen Kontext, als wenn die Maus über ein Solid (geschlossener räumlicher Körper) oder eine Fläche bewegt wird. Wärend der Mauszeiger in den Geltungsbereich eines Objekts eindringt, werden im Hintergrund bereits die relevanten Daten zum jeweiligen Objekt geladen und beim Maus-Stillstand als Tooltip angezeigt. Während dessen werden im Kontextmenü die objektspezifischen Einträge geladen. Bei übereinander liegenden Objekten muss das dem Benutzer räumlich am nächsten liegende Objekt gewählt und aufbereitet werden. Gleichzeitig eine Auswahlliste der unmittelbar darunter liegenden Objekte erstellt werden. Das waren nur ein paar Beispiel aus einem breiten Reportoar. Wie du siehst gehen während einer CAD-Session eine gewaltige Menge and Daten hin und her. Da kommt nicht einmal eine sehr schnelle LAN-Verbindung mit um in einem erträglichen Maß zu arbeiten. Implementiere statt dessen ein vernünftiges PDM (Product Data Management) dann hast du alle Probleme auf einmal erschlagen: remote Anbindung incl. Authentifizierung Vaulting für vernünftige Teamarbeit Datesicherheit durch Redundanz (beim Check-Out wird eine Kopie der angeforderten Daten auf die WS des jeweiligen User kopiert) Integriertes Backup System Gerade bei CAD-Anwendung solltest du dein IT-Denken umstellen, denn hier gelten ganz andere Anforderungen. Unterhalte dich einmal zwanglos mit einem CAD-Anwender oder Konstrukteur :) Servus, Klaus

Die deutschsprachigen MSDN-Foren sind nicht sehr gut besucht. Als alternative kannst du mal im .NET-Forum.de vorbeischauen.Ich bin mir im MSDN-Forum nicht sicher welches dein Post ist. Ich nehme einfach mal an es war der letzte erstellte vom 19.06.2009 bei dem es um Datenbindung geht. Eines der besten Tutorials zu dem Thema ist die Data Access Tutorials Site auf asp.net. Servus, Klaus

Hallo Mull, In VS ist er jetzt "fest eingebunden". Um den ToolKit in jedem Projekt automatisch zu verwenden, kannst du dir ein ProjektTemplate erstellen. Doch dazu brauchst du erst ein Projekt in dem der ToolKit läuft :) Bevor wir hier wild rumspekulieren, möchte ich dich gerne an das SubForum für den ASP.NET AJAX Control Toolkit auf ASP.NET Forums verweisen. Da lesen auch die Entwickler des ToolKit mit. Ich bin mir sicher, dass dir dort am schnellsten geholfen werden kann. Servus, Klaus

Nicht so schlimm :) Das heist lediglich, dass die dll von VS geladen wird und die Controls als solche erkannt werden. Auch wenn du die Controls jetzt auf deine WebForm ziehen kannst, muss die Assembly der Controls noch in der web.config registriert werden. Da hackt es wars***einlich. Am einfachsten versuchts du einmal eines der Beispiele aus dem ToolKit in VS zu öffnen und mal in VS laufen zu lassen. Wenn das Beispiel läuft, hast du ein Problem mit der Registrierung in der web.config deines Projekts. Schau dir dann die web.config des Beispiel-Projekts an. Befor du ein Beispiel aus dem ToolKit in VS öffnest, kopier es am besten auf eine andere Partition. Aber auf alle Fälle nicht im Program Files Ordner öffnen. Vista mag gar nicht, wenn Anwendungen in den Programme-Ordner schreiben :) Vista != XP :) Servus, Klaus

Hallo mull, Sollte kein Problem sein. Du verwendest also nicht den VS-Developmentserver sondern den IIS von Vista. Mit dem IIS7 benötigst du einige Einstellungen in der web.config. Erstelle einfach ein neues Web-Projekt in VS und vergleiche die web.config des neuen Projekt mit deiner aktuellen. Im untersten Bereich der neuen web.config wirst du einige Änderungen betreffs IIS7 sehen. Du verwendest aber schon die AJAX-Extensions von ASP.NET? Servus, Klaus

Hallo, SQL Express ist keine Trial, sonder ein eigenes Produkt. Falls Du mit "Konsole mit den Datenbanken und Tabellen" das Sql Server Management Studio meinst, so ist das in der Standard Express Version nicht enthalten. Du kannst es hier seperat herunterladen. Falls Du auch die erweiterten Feature, wie etwa Volltextsuche und Reporting, verwenden willst solltest Du die SQL Server 2005 Express Edition with Advanced Services verwenden. Das ist das Management Studio ebenfalls bereits enthalten. BTW: Falls Du die Möglichkeit hast zu wählen, solltest du dich für SQL 2008 Express entscheiden. Sie ist mit den gleiche Features erhältlich wie die Version 2005, allerdings mit allen Neuerungen der Version 2008. Servus, Klaus

Hallo Zahni, natürlich könnte man den Speicherverbrauch begrenzen, sowie diverse andere Kenngrößen. Doch wozu sollte man das tun? Der SQL sollte, entsprechende Datenbankgröße und Nutzerzahlen vorausgesetzt, die einzige Anwendung auf der jeweiligen Box sein. Ich will jetzt bestimmt keine Grundsatzdiskussion vom Zaun brechen :) Servus, Klaus

Guten Morgen Philip, Der SQL-Server lebt vom RAM und verwendet so viel wie er vom OS bekommen kann. Wozu währe denn der RAM sonst da? Der SQL-Server ist mittlerweile fast ein eigenständiges OS, oder zumindest eine sehr komplexe Anwendung mit einer ausgereiften Speicherverwaltung. SQL-Server verwendet den RAM um die oft benötigten Datensätze sowie die entsprechenden Indizes vorzuhalten. Glaube mir, Du willst keinen SQL der die Datensätze erst jedesmal von der Platte liest und nach jeder Transaktion die Daten sofort auf die Platte schreibt und aus dem RAM entfernt. Servus, Klaus

Hallo Markus, nein, nur die .NET Runtime, aber die brauchst Du ja sowieso. Im installationsverzeichnis des .NET Framework, normalerweise unter %SystemRoot%\Microsoft.NET\Framework\[Version]\ findest du die caspol.exe. Um deiner Assembly MagicLibrary z.B.: Fulltrust zu erteile gibst du in einer CommandBox ein: caspol -af MagicLibrary Aber normalerweise macht das der Windows Installer, wenn Du ein Setup-Projekt verwendets. Ohne Setup musst du an die Kommandozeile. Servus, Klaus

Ich kenne das Tool welches Du zum löschen verwendest nicht. Schau mal ob es da einen Parameter gibt um auch versteckte Dateien zu löschen (Attribute H). Wenn nicht verwende in deinem Script das Kommandozeilenprogramm attrib.exe. In etwa attrib -h [dein Dateipfad]\*.tmp Servus, Klaus

Hi SilverDrag0n, Dann scheint eine Betriebssystem-Sperre auf den *.tmp Dateien zu sein. Check mal ob irgend ein Programm noch auf die Dateien zugreift. Mit dem ProcessMonitor von Sysinternals geht das wunderbar. Servus, Klaus

Hallo Andreas, Wofür der Entwickler die Daten der Datenbank braucht verstehe ich nicht. Normalerweise reicht die Datenbank mit ein paar Beispieldatensätzen vollkommen aus. Soll nicht mein Problem sein :D Viellicht kann einer Deiner Entwickler sich ja eine kleine Anwendung "stricken" mit der er mittels der SQL Server API die Datenbank synchronisiert. Damit hatt er ganz andere Möglichkeiten als Du auf der Oberfläche. Für dich hier noch ein paar Infos die die MSDN hergibt: Suche nach: Datenbank kopieren Kopieren von Daten zwischen Servern Vielleicht kommst du ja damit weiter. Servus, Klaus

Hallo Hans. genau dass versucht er ja. Wie Du im ersten Post lesen kannst: hat er auf seinem Laptop die SQL Developer Edition. Wenn Andreas mit dem <Datenbank kopieren> nur auf Probleme stößt, sollte er wirklich die Lösung von Freundlicher in Betracht ziehen. Servus, Klaus