auf klassische Access-Datenbanken (Dateierweiterung .mdb) kannst du nur aus 32-Bit-Applikationen zugreifen, da der JET-Treiber, der dazu verwendet wird, nur in 32 Bit vorliegt.
EDIT:
Verwendest du die Jet-MDB-Datenbank, oder das neue .ACCDB-Format?
Wenn du ACCDB-Verwendest - vergiss meine Antwort ;)
Office 365 wird vermutlich auf der Maschine jedoch als 64 Bit installiert sein, wodurch sich dein 2. Problem ergibt (vermute ich jetzt mal) - die 32 Bit-Anwendung, die zwar jetzt die Datenbank lesen kann, kann mit den 64-Bit Komponenten vom Office nicht mehr kommunizieren.
Problem 1 lässt sich somit nur umgehen, wenn du eine Datenbank verwendest, die auch mit 64 Bit läuft (SQLite, SQL Server). Dann kannst du eine 64-Bit-Applikation bauen, die dann auch mit dem (vermutlich) 64-Bit-Office läuft.
Deine Main-Funktion sowie Console.WriteLine sind beides Methoden, das ist soweit korrekt. Ich würde es in deinem Fall jedoch so spezifizieren:
Deine "Main"-Methode ist eine Methodendeklaration, d.h. du definierst bzw. erstellst selbst eine Methode, die bestimmte Anweisungen ausführt
Das Console.WriteLine ist ein Methodenaufruf, d.h. du rufst eine bestehende Methode des .NET Frameworks, oder auch eine selbst von dir deklarierte Methode auf.
Mit diesen Begriffen gilt dann folgendes: Du kannst keine Methode innerhalb einer anderen Methode deklarieren (Ausnahme sind anonyme Methoden), allerdings kannst du beliebige Methoden aus einer anderen Methode aufrufen. Und dies sowohl mehrfach, als in Schleifen und auch verschiedenen Ebenen.
Ist eventuell die 32Bit-Version von Excel oder der Runtime installiert?
Wenn ja - muss deine Applikation auch als x86 in 32 Bit kompiliert werden, da ansonsten der 64-Bit Prozess nicht auf den Treiber zugreifen kann. Das ist auch eine kleine Stolperfalle, gleiches z.B. wenn du per OleDB den JET-Treiber verwenden willst.
Bei mir war's auch der Arbeitsspeicher (Notebook), bei einem im Kurs die Grafikkarte, beim nächsten die Festplatte - eigentlich haben alle relativ einfache, nicht komplexe Themen gehabt - eben um Sie in den 15 Minuten durchzubringen (4-Stufen-Methode).
Ein unrühmliche Ausnahme bilden hier aber tatsächlich die Zertifikate von StartSSL mit denen das TimeStamping nicht funktioniert. Diese Zertifikate sind also für das Codesigning nicht wirklich zu empfehlen.
Das kann ich so nicht bestätigen - ich habe jetzt die StartSSL-Zertifikate seit ein paar Jahren in Verwendung, nachdem die von K-Software vor ein paar Jahren immer sehr "kompliziert" waren was Einzelunternehmen angeht, da hier immer die Unterlagen nicht passten.
Und meine StartSSL-Zertifikate kann ich genauso über den Verisign-Timestamp-Server timestampen lassen, das geht ohne Fehler oder Probleme. Am Ende ist in der signierten EXE-Datei dann auch der Zeitstempel drin.
die Fehlermeldung sagt doch eigentlich bereits alles ;)
Zitat
Es wurde kein Argument angegeben, das dem formalen Parameter "Label_Wort" von "Form1.WordMethode(Label)" entspricht.
Dem Methodenaufruf fehlt also ein Argument. Deine Funktion in Form1 erfordert ein Argument, da du das bei der Funktion so definiert hast (das in den Klammern, "Label_Wort"):
public static void WordMethode(System.Windows.Forms.Label Label_Wort)
{
Label_Wort.Text = Convert.ToString(wort);
}
Daher musst du beim Aufruf auf dieses Argument natürlich mit angeben, also dein Label_Wort:
Form1.WordMethode(Label_Wort);
Ansonsten weiß die Funktion ja nicht, welches Label es verwenden sollte.
Andere Möglichkeit: Hast du eventuell keine Schreibrechte auf die Datenbank auf Windows-Ebene? Also Datenbank Schreibgeschützt oder Benutzer ohne Berechtigung?
Du kannst dem Tool ILMerge mehrere DLLs in deine EXE mergen, damit hättest du am Ende nur noch eine Datei die du weitergeben musst. Das klappt aber nur mit .NET Assemblys soviel ich weiß, aber das sollte ja in Ordnung sein.
Ich behaupte jetzt einfach mal dass das nichts mit dem Programmieren zu tun hat. Kann es sein, dass die Access-Datenbank, also das MDB File zu deinem C# Projekt gehört, also im Visual Studio im Projekt eingebunden ist? Und sich die MDB auf diedu im Programm zugreifst im gleichen Ordner befindet wie deine EXE Datei?
Falls ja, ist in den Eigenschaften der Datei im Visual Studio eventuell eingestellt dass die Datei beim erstellen des Projektes neu in das Ausgabeverzeichnis kopiert wird - und damit deine Änderungen wieder überschreibt.
Prüf das auch mal - hört sich für mich sehr stark danach an.
Wobei das auch seltsam wäre wenn manche Boxen gehen und manche nicht. Eventuell hilft ein Blick ins EventLog von Windows - wenn es am Message Box Default Reply liegen würde, würde das normalerweise was geloggt werden.
es gibt für die "klassische" JET-Engine mit den alten Treibern (und mit den klassischen MDB-Dateien von Access) keine Möglichkeit, diese unter 64 Bit zum laufen zu bekommen. (gibts auch einige Microsoft-Infos dazu How to get a x64 version of Jet?).
Die einzige Möglichkeit ist entweder, die Anwendung als 32 Bit zu kompilieren, dann gehen auch die JET-Geschichte wieder. Alternative, wenns 64 Bit sein muss, musst du auf den ACE-Treiber von Microsoft umstellen, der zusätzlich installiert werden muss. Der soll das auch können, mehrere Firmen machen das auch über die ACE-Treiber, um die Kompatibilität zu gewährleisten (Verwendung von 64-Bit-Applikationen mit Microsoft Access-Datenbankdateien).
Da wird aber ADOX auch nicht funktionieren, da es hier keine 64 Bit Version von gibt - hier muss alles auf ACE umgestellt werden.
Gibt einiges dazu auf Stackoverflow:
Zitat
If you deploy your application on a 64 bit machine your code couldn't use ADOX via JET.OleDB.4.0
If this is the case, then, a fast solution could be to change your target architecture to x86.
Otherwise you could try to download and install on the target machine the 64bit version of Microsoft Access Database Engine drivers, but I don't know if they support ADOX. You will also need to change your connection string
Mit dem HTML Agility Pack (http://htmlagilitypack.codeplex.com/) könnte man schon mal die "quasi" XPath-Query auf ne HTML-Seite durchführen. Funktioniert eigentlich relativ reibungslos, auch wenn natürlich die HTML-Seite kein XML ist...
die Datenbank wird, soweit ich weiß, beim anhängen direkt auch ohne irgendeine Bearbeitung auf das aktuelle Format des SQL-Servers aktualisiert. Ein anhängen an eine alte Version ist dann nicht mehr möglich, nur noch ein Anhängen an eine gleiche oder neuere Version.
Ich denke nicht dass man das unterbinden kann, da der 2012er einige Änderungen an der Datenbankdatei durchführt, die halt der 2008er nicht mehr kann.
Dazu gibts auch im Internet ein bisschen was dazu, so wie ich das sehe ist die einzige Möglichkeit die Datenbank wieder an den "alten" Server zu bekommen das erzeugen von dementsprechenden Generate-Skripts, um die Datenbank im alten Server wieder zu erstellen:
versuch mal im Connection-String den InitialCatalog anzugeben, damit der SQL Server auch weiß, in welcher Datenbank sich die Tabelle "tblOverview" befindet. Bisher gibst du Ihm mit der Data Source ja nur den Server, aber nicht die Datenbank selbst.
Also z.B.:
Data Source=ARBEITS-PC;Integrated Security=True;Connect Timeout=15;Encrypt=False;TrustServerCertificate=True;Initial Catalog=Test"
Dann sollte er das Objekt eigentlich auch finden ;)
wenn ich das ganze jetzt richtig verstehe, müssten doch die Befehlszeilenargumente das richtige sein, was du suchst?
Wenn du eine Datei auf das Desktop-Icon deiner Applikation ziehst, wird normalerweise die Anwendung gestartet, und die Datei als Befehlszeilenargument übergeben, oder irre ich mich da?
mit der DockPanel Suite oder entsprechenden kostenfpflichtigen Komponenten (DevComponents, DevExpress, Infragistics...) lässt sich sowas alternativ auch umsetzen. Da ist halt dann schon alles fertig ;)
also der Connector muss selbst nicht auf dem Ziel-System installiert werden (über den MySQL-Installer).
Ich liefere die MySql.Data.dll auch mit meinem Programm nur im Programmverzeichnis mit, eine Installation ist hier nicht notwendig, es reicht, wenn sich die DLL im Programmverzeichnis mit den anderen Assemblys befindet (oder der bin-Ordner im Webprojekt).
du kannst die MySQL-Internen Tabellen abfragen, in denen die einzelnen Tabellen und Datenbanken verzeichnet sind. Das könnte dann in etwa so aussehen:
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'DATABASENAME' AND table_name = 'DATATABLENAME'"
Mit nem ExecuteScalar mit dem oben genannten SQL-Befehl solltest du herausbekommen ob die Datenbank existiert, oder nicht. Zusätzlich kannst du noch prüfen, ob eine Tabelle darin besteht, oder ob die Datenbank leer ist.
also ich kann hier meinen Senf zu dem Kobo dazugeben, den habe ich nämlich ;) (Kobo Touch, http://www.kobobooks.de/touch).
Bisher habe ich überwiegend gute Erfahrungen mit dem Kobo gemacht. Hauptgrund, warum es ein Kobo wurde, war der Preis und der Wunsch, nicht unbedingt von Amazon mit den eBooks abhängig zu sein.
- Touch Bedienung sehr gut möglich, auch das Display ist sogar in der Sonne Top lesbar
- Der Kobo unterstützt mehrere Wörterbücher (Kindle glaub ich nur ein Deutsches).
- Übersetzungsfunktion z.B. bei Englischen Büchern klappt sehr gut
- Integrierter Shop kann mit Kreditkarte gut benutzt werden, kostenlose Leseproben vorhanden
- eBooks aus anderen Stores (Weltbild, buch.de, Libri...) in offenen Formaten können auch importiert werden
- Bilder können auch hochgeladen werden (aber sind natürlich nur Schwarz-Weiß)
- Sync-App zum Lesen und Syncronisieren für den PC vorhanden
- Kleines Sudoku und Webbrowser vorhanden (aber nur Schwarz-Weiß ;))
- Relativ häufige Updates, Top-Akkulaufzeit (auf 4 Monate jetzt 3 mal geladen).
- "Reading-Life": Posten von Status-Mitteilungen (aktuelles Buch, Lesezeit, Statistik) auf Facebook.
Negative Punkte gibt's eigentlich nur wenige:
- Integrierter Shop hat hauptsächlich Englische Bücher, also weniger Deutsche Bücher (wobei das weniger Problematisch ist, da Medien auch aus deutschen eBook-Shops gekauft werden können).
- PDFs teilweise langsam, daher Konvertieren angebracht
Aber ansonsten bin ich mit dem Kobo Touch vollstens zufrieden, und kann den eigentlich nur weiterempfehlen!
das Event ist ja lt. MSDN WebBrowser.NewWindow-Ereignis vom Typ "CancelEventHandler", dadurch meckert der Compiler natürlich, wenn du das ganze als "normalen" System.EventHandler verwenden willst.
Folgendes sollte gehen:
test.NewWindow += new System.ComponentModel.CancelEventHandler(webBrowser1_NewWindow);
test.NewWindow += new CancelEventHandler(webBrowser1_NewWindow);
test.newWindow += webBrowser1_NewWindow;
ergibt das aber dann nicht das Problem, wenn jemand den höheren Build ohne eine bereits Installierte Version installiert, dass der dann keine Datenbank hat?
Weil eine Vorgängerversion war ja nicht installiert, daher auch keine Datenbank auf dem PC vorhanden?
Leider kenn ich mich mit dem VS-integrierten Installer nicht wirklich aus, aber ich habe jetzt bei einer kurzen Suche des öfteren gelesen, dass das mit dem "nicht-überschreiben" so ohne weiteres nicht im VS gemacht werden kann.
Ich habe das selbe Vorhaben (Datenbank wird einmal bei einer erstinstallation installiert, danach weder deinstalliert noch bei einem Update überschrieben) mit InnoSetup ohne Probleme umsetzen können.
InnoSetup bietet bei Dateien z.B. folgende Flags, die das möglich machen:
onlyifdoesntexist - Kopiert eine Datei nur, wenn es sie noch nicht gibt
uninsneveruninstall - Deinstalliert eine angegebene Datei nicht.
Bei verschiedenen Datentypen wirst du immer ein bisschen was anpassen müssen, seis die Hochkommas, oder andere Sachen, die jede Datenbank etwas anders macht. Bei MySQL ist dann unter Linux z.B. auch zu beachten, dass es alles Case Sensitive ist.
Hier ist ein O/R-Mapper das vernüftigste, da viele hier das Mapping und die SQL-Befehle automatisch korrekt absetzen.
Deine Spalte "maid" ist die ID des Mitarbeiters, oder? Dann ist die Spalte vermutlich eine Zahl - also gehören hier bei der Abfrage keine Hochkomma hin, da diese einen String kennzeichnen.
Ansonsten kannst du die Typen "DbCommand", "DbConnection", "DbDataAdapter" usw. verwenden, die keinen speziellen Datenbanktypen zugeordnet sind. Also z.B.:
DbConnection Test = new MySqlConnection(ConnectionString);