Firebird Client Sortierung funktioniert nicht

[mkinzler]

Zitat:

Auf dem Vereinsrechner, wo kein firebird-server installiert ist, sonder nur die Client-Version, sortiert das Programm falsch.

Hier steht, dass nur der Client installiert ist, von embedded steht hier nichts.

[Luckner]

Ein Server ist nur auf meinem Entwicklungsrechner installiert. Der Kunde hat keinen Server, nur 1 Arbeitsplatz. Also "embeddet Server". Finde den Fehler nicht. Programm ist identisch, die Datenbank auch. Hab das Gefühl, das der Server das View richtig sortiert, die embeddet Komponenten jedoch nicht.

[DeddyH]

Hast Du auch die Verzeichnisstruktur so angelegt wie in der README_EMBEDDED.txt beschrieben?

[Luckner]

Na dann werde ich die erst mal suchen. Mal schauen, ob ich da die Lösung finde.

[DeddyH]

Falls Du sie nicht finden solltest:

Zitat:

3. USAGE

Just copy fbembed.dll, icudt30.dll, icuin30.dll and
icuuc30.dll into the directory with your application.
Then rename fbembed.dll to either fbclient.dll or
gds32.dll depending on your database connectivity software.
Then start your application and it will use the embedded
server as a client library and will be able to access
local datasases. You should also copy firebird.msg and
firebird.conf (if necessary) to the same directory.

If external libraries are required for your application,
then you should have them separately. Most probably, it
will be INTL support (fbintl.dll and fbintl.conf) or UDF
libraries. To be able to use them, you should place them
into the directory tree which emulates the Firebird server
one, i.e. has subdirectories like /intl or /udf:

c:\my_app\app.exe
c:\my_app\gds32.dll
c:\my_app\ib_util.dll
c:\my_app\icudt30.dll
c:\my_app\icuin30.dll
c:\my_app\icuuc30.dll
c:\my_app\firebird.conf
c:\my_app\firebird.msg
c:\my_app\intl\fbintl.dll
c:\my_app\intl\fbintl.conf
c:\my_app\udf\fbudf.dll

If you want to place the Firebird files (excluding the
renamed fbembed.dll) in another directory, you need to
modify your firebird.conf and set RootDirectory to the
Firebird directory tree. Example:

c:\my_app\app.exe
c:\my_app\gds32.dll
c:\my_app\ib_util.dll
c:\my_app\icudt30.dll
c:\my_app\icuin30.dll
c:\my_app\icuuc30.dll
c:\my_app\firebird.conf
d:\fb\firebird.msg
d:\fb\intl\fbintl.dll
c:\fb\intl\fbintl.conf
d:\fb\udf\fbudf.dll

firebird.conf:
RootDirectory = d:\fb

[Perlsau]

Der User Luckner hat zwei Sätze veröffentlich, die sich durch die Nichteinhaltung der richtigen Terminologie als verwirrend erweisen, gerade für Leute, die sich mit Firebird (noch) nicht gut auskennen:

Zitat von Luckner:

Der Kunde hat keinen Server, nur 1 Arbeitsplatz. Also "embeddet Server".

Kein Server, und dann doch Server? Weiter oben schrieb er:

Zitat von Luckner:

Mit server funktioniert es, ohne nicht.

Hält man sich an die Formulierung, die von euch eingefordert wird, nämlich auch die Embedded-Variante als Server zu bezeichnen, würde diese Aussage von Luckner bedeuten, es gäbe überhaupt keine Bereitstellung von Firebird-Datenbank-Funktionalität, weder durch einen Firebird-Server noch durch die Firebird-Embedded-DLL.

Mensch Leute, es geht mir doch nicht darum, daß "sich die Jünger an die Vorgaben eines religösen Führers halten müsse, da Ihnen sonst die ewige Verdammnis blüht" oder um ähnlichen Quatsch. Hier werde ich vollkommen mißverstanden und fehlinterpretiert, ja fast verhöhnt mit übertriebener Polemik. Kann (oder eher: will) das denn keiner nachvollziehen?

[Daniel]

Zitat von Perlsau:

Kann (oder eher: will) das denn keiner nachvollziehen?

Ich kann es nicht. Aus dem von Dir zitierten Satz wird für mich ersichtlich, dass ein FireBird Embedded zum Einsatz kommt und kein separat installierter Server. Sprachlich mag es nicht schön sein mit "Server aber doch kein Server", aber für mich wurde klar, was gemeint ist. Trotzdem ist es völlig legitim, hier zu fragen, ob wirklich ein FireBird Embedded gemeint ist, weil man sonst Ratschläge gibt, die vielleicht gar nicht zum Problem passen. Aber wie sich dann daraus eine Diskussion entwickeln kann, ist mir schleierhaft.

[haentschman]

Irgendwie erinnert mich das an mein liebes Frauchen. Die kann auch mit wachsender Begeisterung ein kleines Thema totdiskutieren...

[hoika]

Hallo,

dann muss ich doch auch mal

http://www.firebirdsql.org/manual/ufb-cs-embedded.html

Steht doch alles da ...

Firebird ist immer ein Server, weil es ja Daten bedient (to serve data).

Richtig ist aber:
Wir haben verschiedene Namen für das gleiche Ding.
Und fragen muss man doch können, gerade wegen der unterschiedlichen Architektur.

An den TE:
Was macht ein

Select Name From Employee
Order By Name COLLATE "dein collate-Name"

Sortiert das richtig ?

Und zeig uns mal den Create Table Script und ein paar Bsp.-Daten.


Heiko

[Sir Rufo]

Vor allem, was machen wir denn jetzt mit der "Terminologie"?

Die Perlsau Variante oder die von Firebird selber:

http://www.firebirdsql.org/manual/fbmetasecur-embedded.html

Embedded Firebird Server

There is a special version of the Firebird server referred to as “embedded”. This is a special client library that includes the server itself. When an application links to this library it loads the server and allows direct access to any database that is accessible on the local computer. This version of the server does not use a security database. The user name specified during the “logon” (no password authentication occurs) is used to manage user access to database objects (via SQL permissions) but if that user name is SYSDBA (or the owner of the database) then unrestricted access is possible.

The features of embedded are useful for developers wanting to create easy to distribute single-user applications that do not need security.

From that brief description it appears that having an embedded server client installed on a server hosting other databases could present itself as a major security risk. In reality the risk is no greater than if the embedded client did not exist.

When an application loads the embedded server, the server operates in the application (and therefore the user's) security context. This means that the embedded server will only be able to access database files that the user could access directly through the operating system. Giving an untrusted user access to install programs on a secure server is bad news in any case, but provided you have specified appropriate file permissions on secure databases, the embedded server itself is no threat.

The threat comes from all the other things that the user could install.

The fact that the embedded server exists only serves to highlight what is possible given direct access to a database file, especially in an open source environment. If it did not already exist then it would certainly be possible for someone to compile an equivalent capability.

Quelle

Oder haben die sich da vertan? Wer sagt es denn jetzt den Kindern?