No Bytes

When using ODBC, there are some facts to be considered. One of these facts is good to know when one is about to create a new database with an ODBC connection. General you should avoid ODBC if possible. But in some cases this is not possible because ODBC is still the only connection you have. This can happen if you use (for example) Mircrosoft Access to connect to a MySQL Server or a similar scenario. If you already worked successfully with data on that kind of connection, but now you have to create a database, there will occur a problem. Oh the existing connection you usually will have no success when trying to create a database because you maybe dont have the privilege. But even if you have, there will occur a problem.

Working with a database can be so easy - as long as you don't need to care about localization or languages with more or other letters than english. One of these Languages is German. And here the problem starts... Introduction Let's look at a simple scenario: Inserting a text with German letters like ä, ö, ü and ß into the Oracle 11g database. And right now there already could be a problem when trying to select it again. So what is the problem here? Actually the problem itself is very simple: The character encoding. However the solution is not as simple. I tried to connect to Oracle via an ODBC connection from Lazarus IDE for inserting german press releases with a lot of Umlauts (äöü). The result in the database was a mess. So how to solute this mess? The "problematic chain" First of all we have to consider that different operating systems have different character sets. Usually current Linux distributions have a Unicode character set in contrast to Windows, u

Because my Article about how to teach Mircosoft Access in Oracle transactions seems to be very popular, I decided to post an English version of it. In future I will concentrate to write in English. Microsoft Access is a widely used product in a number of companies in all industries. This is because the Microsoft Office package is widely used, and access solution 'so ubiquitous. Unfortunately, this solution has its drawbacks. These are noticeable when man realizes an Access front end for a database connection. One of these drawbacks is the lack of ability to implement transactions or to use stored procedures and table functions. About the Access interface alone this is not possible. While there is an SQL pass-through to execute DBMS-proprietary SQL queries, but these are often only possible static and need to be adjusted. Visual Basic for Applications (VBA briefly) here can provide some relief. So it is possible, for example, assign the button controls of an Access form VBA mac

Microsoft Access ist ein vielgenutztes Produkt in zahlreichen Unternehmen aller Branchen. Dies liegt darin begründet, dass das Microsoft-Office-Paket weit verbreitet ist, und die ,Access-Lösung' somit überall vorhanden. Leider hat diese Lösung auch Nachteile. Diese machen sich bemerkbar, wenn mann ein Access-Frontend für eine Datenbankanbindung realisiert. Einer dieser Nachteile ist die fehlende Möglichkeit, Transaktionen zu realisieren oder auf Stored Procedures sowie Table-Functions zurückzugreifen. Über die Access-Oberfläche allein ist dies auch so nicht möglich. Es gibt zwar einen SQL-Pass-Through, um DBMS-proprietäre SQL-Abfragen auszuführen, jedoch sind diese oftmals nur statisch möglich und müssen angepasst werden. Visual Basic for Applications (kurz VBA) kann hier eine gewisse Abhilfe schaffen. So ist es  z. B. möglich, den Button-Steuerelementen eines Access-Formulars VBA-Makros (Subs) zuzuweisen, und diese beim Klicken auszuführen. Ereignisse wie dieses OnClick-Ereign

Excel ist das neben Word vermutlich am weitesten verbreitete Office-Produkt in Unternehmen sowie auf privaten Rechnern. Und Excel hat schon sehr umfangreiche Funktionen. Interessant und knifflig wird es aber, wenn man auf Daten aus einer Datenbank (Oracle) zugreifen möchte. Erforderlich hierfür ist eine eingerichtete ODBC-Datenquelle. Über das Menü "Daten", Untermenü "Aus anderen Quellen", Eintrag "Von Microsoft Query" kann man nun über den sog. DSN und Microsoft Query Daten aus der Datenbank abrufen. Möchte man aber eine proprietäre Oracle-Abfrage formulieren, wird Microsoft Query die Anfrage nicht verarbeiten könnnen. Der dafür liegt in der Vorverarbeitung der eingegebenen Statements. In Query selbst gibt es keine Möglichkeit, dies zu umgehen - in Excel selbst schon. Daher wählt man über eine "Dummy"-Abfrage einige Daten aus und manipuliert das SQL-Statement postwendend. Im abschließenden Query-Dialog wählt man "Daten an Excel zurückgeben

Um Oracle-Daten in Office-Anwendungen nutzen zu können, benötigt man in den meisten Fällen eine sog. ODBC-Datenquelle (DSN). In Windows 7 findet man eine Möglichkeit zu deren Verwaltung unter "Systemsteuerung", "Verwantung", "Datenquellen (ODBC)". Hier sind auch bereits vordefinierte Datenquellen enthalten (z. B. für Excel-Datenblätter, Access-Dateien oder auch Microsoft SQL-Server). Um Oracle als ODBC-Datenquelle nutzen zu können, benötigt man den passenden ODBC-Treiber für die zu verwendend Datenbankversion. Diese kann man nach kostenloser Anmeldung im Oracle Software Download herunterladen nach vorheriger Registrierung. Zum Erstellen der ODBC-Datenquelle muss eigentlich nicht viel beachtet werden, wenn man denn den richtigen ODBC-Treiber (richtige Architektur 32/64-Bit, richtige Datenbankversion) heruntergeladen hat. Das Feld "Data Source Name" bekommt den Namen, den die Datenquelle erhalten soll. "TNS Service Name" referen