MS SQL 2000 Server

[Peeters]

Hallo Gleichgesinnte,

wir stellen demnächst in der Firma auf MS SQL 2000 Server um, nun habe ich eine Frage. Bei meiner alten Datenbank benötigte ich nur eine Handvoll Dateien um die Datenbank als solche auch Lokal zu öffnen ohne das eine wirkliche Server/Client-Beziehung steht. Ist das auch mit MS SQL 2000-Datenbank möglich? Und wenn ja, welche Dateien benötige ich?

Besten Dank im voraus.

[generic]

msde, ist die engine. die gibts als "kleinen" download bei mircosoft.

die msde ist binary kompatibel. einschränkung max. 5 user.

[Peeters]

Danke für die schnelle Antwort, ich habe bei Microsoft eine GER_MSDE2000A.exe gefunden die aber 45MB groß ist. Ist das die richtige?

[Phoenix]

Das ist die alte.

Die neue hat schon das ServicePack des MS - SQL - Servers drin, heisst ger_sql2kdesksp3.exe und ist.. erm.. ganze 75 MB gross :)

Zum Zugriff nimmst Du dann z.B. einfach ADO / MDAC.

[Bernhard Geyer]

Für eine Lösung, welche keine "richtige" Client/Server-Architektur benötigt und nur auf einem einzelnen Rechner (evtl. nur mit einem Benutzer) laufen soll ist m.E. der MS-SQL-Server (auch als MSDE) die Falsch wahl.

1, Installationsaufwand: Du musst die x-MB's installieren (Admin-Rechte nötig), evtl User einrichten, auf jedenfall dafür sorgen das das leere Defaultpasswort für den Admin geändert ist (SQL-Blast-Wurm läßt grüßen) und deine Datenbank anlegen
2, Du benötist genügent Platz allein für die Datenbank-Engine sowie auf deiner Distribution (CD minimum), Internetdownload???
3, Altere Rechner evtl mehrmals gebootet werden, da all die Sachen wie halbwegs aktueller IE, SP'S, ... vorhanden sein müssen


Ich würde eine auf wenige User optimierte Lokaldatenbank wie ADS Local Server, TurboDB, ... verwenden. Diese haben folgende Vorteile:

1, Keine Installation nötig. Maximal 2-3 DLL's im Anwendungsverzeichnis
2, Kleiner Overhead. ADS im Lokalbetrieb z.B 1,5 MB
3, Keine Vorraussetzungen. Laufen auch unter 95 noch

[trifid]

@Peeters

Zitat:

die Datenbank als solche auch Lokal zu öffnen ohne das eine wirkliche Server/Client-Beziehung steht

für die DB-Verbindung auf Client-Seite brauchst du die MDAC von Microsoft
diese findest du hier
http://msdn.microsoft.com/data/downl...s/default.aspx

Zitat:

Ist das auch mit MS SQL 2000-Datenbank möglich? Und wenn ja, welche Dateien benötige ich?

a) MS SQL Server 2000 Standard und aufwärts
da ist ein Installationssatz für den Server beim Kauf in Form einer CD oder DVD mit
dabei :wink:
b) MSDE 2000 oder MSDE V2.0
b.1) "Microsoft eine GER_MSDE2000A.exe gefunden die aber 45MB groß ist. Ist das die richtige?"
das kommt auf die Lizenzbedingungen an, die du erfüllen musst bzw. viele User, Komfort, etc. du haben möchtest
b.2) @Phoenix

Zitat:

Das ist die alte.

das ist leider nicht richtig. Die "MSDE 2000 Release A" ist später entstanden und hat
im Detail ein anderes Verhalten wie die MSDE 2000 SP3
Die MSDE 2000 Release A wird gleich mit dem SP3 ausgeliefert
näheres irgendwo im www.entwickler-forum.de
Ich denke die Größe eines Installationssatzes dürfte heutzutage nicht mehr die Eintscheidung einer Datenbankauswahl sein :wink:

Zitat:

Und wenn ja, welche Dateien benötige ich?

Server: Installationssatz des DB-Server von Microsoft (egal ob MS SQL Server 2000 oder MSDE)
Client: Installationssatz der MDAC von Microsoft

[generic]

bevor hier jemand mit ads anfängt dann doch lieber firebird mit der firebird-embedded
ist nur 1,5 MB

-----------------------------------------------------------
Firebird 1.5 Embedded Server notes
-----------------------------------------------------------

1. GENERIC INFORMATION

The embedded server is a fully functional server linked
as a dynamic library (fbembed.dll). It has exactly the
same features as the usual server and exports the
standard Firebird API entrypoints.

2. ISSUES AND LIMITATIONS

2.1. Registry

The Firebird registry entries are ignored. The root
directory of the embedded server is the directory of
its binary file (library).

2.2. Database access

The embedded server can act as a true local server
accessing databases on a local machine, and as a remote
gateway which redirects all network calls to another
hosts (i.e. works as a client library). Note that you
cannot connect to the local standalone Firebird server
using the local connection string (without a host name).
It applies to IPC connections only, because they use
the same format of the connection string; but you can
connect to the local standalone server via TCP/IP localhost
loopback or via the named pipes protocol.

2.3. Authentication and security

The security database (namely security.fdb) is not used
in the embedded server and hence is not required. Any
user is able to attach to any database. Since both
the server and the client run in the same address space,
the security becomes just an agreement between both
sides which can be easily compromised.

But note that SQL privileges are still checked.

2.4. Compatibility

You may run any number of applications with the embedded
server without any conflicts. Having IB/FB server running
is not a problem either.

But you should be aware that you cannot access single
database from a number of the embedded servers
simultaneously, because they have SuperServer architecture
and hence exclusively lock attached databases.

3. USAGE

Just copy fbembed.dll into the directory with your
application. Then rename it 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) 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\firebird.conf
c:\my_app\firebird.msg
c:\my_app\intl\fbintl.dll
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\firebird.conf
d:\fb\firebird.msg
d:\fb\intl\fbintl.dll
d:\fb\udf\fbudf.dll

firebird.conf:
RootDirectory = d:\fb

[trifid]

war nicht am Anfang

Zitat:

wir stellen demnächst in der Firma auf MS SQL 2000 Server um

zu lesen ...

[Phoenix]

Zitat:

Zitat von Peeters

Bei meiner alten Datenbank benötigte ich nur eine Handvoll Dateien um die Datenbank als solche auch Lokal zu öffnen ohne das eine wirkliche Server/Client-Beziehung steht. Ist das auch mit MS SQL 2000-Datenbank möglich?

Sorry, verlesen am Anfang.

Zu Deiner Frage: Nein, das ist nicht möglich.
Die Engine ist ein Service, der auf dem Datenbankserver läuft und die Datenbankdateien exclsuiv für den eigenen Zugriff sperrt.

Du hast also vom Client aus ausschliesslich die Möglichkeit, Dich mit dem Datenbankservice auf dem Datenbankserver zu verbinden und darüber zu arbeiten. Alternativ (aber dazu musst Du lokal zumindest die MSDE selber installiert haben), kannst Du den Datenbankserver beenden, die Datenbankdatei und das Logfile auf den Client kopieren und die Datenbank hier an die MSDE anhängen und damit ausführen.

Imho ein Risiko für die Daten und nicht praktikabel, zudem sehr aufwandig.

[Jelly]

Zitat:

Zitat von Phoenix

Zu Deiner Frage: Nein, das ist nicht möglich.
Die Engine ist ein Service, der auf dem Datenbankserver läuft und die Datenbankdateien exclsuiv für den eigenen Zugriff sperrt.

Also ich meine mal in "Der Entwickler" Zeitschirft gelesen zu haben, daß so was wie Offlinedaten zu funktionieren scheint. Ich muß das mal nachforschen und die Zeitschrift wiederfinden, dann kann ich mehr zu sagen.

Gruß,
Tom

[Peeters]

Junge, Junge,

das sind aber jetzt viele Antworten. Zur Klärung: wir Kaufen den MS SQL 2000 Server kostet glaube ich ca. 6.000 Euro mit Unlimited User. Der Sinn der dahinter steckt ist dieser: In der Firma habe ich die Server/Client-Verbindung wo ich daran Programmieren kann, aber zu Hause habe ich nicht die Möglichkeit, deswegen würde ich die DB kopieren und diese Lokal auf meinen Rechner ausführen wollen.

Deswegen habe ich gefragt. Ich habe vom SQL Server noch keine Ahnung. Und welche Dateien bzw. Software ich dafür brauche.

[trifid]

@Peeters,

Zitat:

deswegen würde ich die DB kopieren und diese Lokal auf meinen Rechner ausführen wollen.

mach in der Firma ein Backup (Datensicherung)

Zitat:

Und welche Dateien bzw. Software ich dafür brauche.

installiere bei dir zu Hause die MSDE 2000 SP3 lokal auf deinen Rechner
und stelle die Daten wieder her mit Hilfe eines Restore (Datenwiederherstellung)
Bevor ein Restore verwendet werden kann, muss natürlich bei dir die Datenbank
auf der MSDE erzeugt sein

wenn die Datenbank allerdings größer 2GByte ist, kannst du die MSDE nicht mehr verwenden.
Dafür gibt es dann den MS SQL Server 2000 Standard oder mehr

[Bernhard Geyer]

Zitat:

Zitat von Peeters

In der Firma habe ich die Server/Client-Verbindung wo ich daran Programmieren kann, aber zu Hause habe ich nicht die Möglichkeit, deswegen würde ich die DB kopieren und diese Lokal auf meinen Rechner ausführen wollen.

Falls Du auf der Arbeit kurzzeitig die Datenbank (nicht das DBMS) deaktivieren kannst, so könntest Du folgendes im Enterprise-Manager machen:
- Mittels Popup-Menüpunkt "Alle Tasks/Datenbank abhängen" diese aus der Liste der Datenbanken aushängen
- Im Dateiverzeichnis die Datenbankdateien (Dat+Log-File) kopieren
- Mittels Popup-Menüpunkt "Alle Tests/Datenbank anhängen" die Datenbank wieder online-Schalten

Daheim hängst Du dann die kopierte Datenbank in die MSDE. Falls Du keinen Enterprise-Manger zuhause hast, so schau dir mal den Befehl sp_attach_db/sp_detach_db-Befehl an.
Dies dürfte schneller gehen als ein Backup/Restore.

[Robert_G]

Zitat:

Zitat von Peeters

...deswegen würde ich die DB kopieren und diese Lokal auf meinen Rechner ausführen wollen.

das ist nicht nur gefährlich (du musst ja erst den SQL Svr abschießen, bevor du die TableSpaces kopieren kannst :shock: ), sondern auch nervig (Kopieren, Restore, etc.).

Warum greifst du nicht einfach von zu Hause auf die DB zu?

p.s.: SQL Svr sucks ;)

[trifid]

@Robert_G,

Zitat:

das ist nicht nur gefährlich (du musst ja erst den SQL Svr abschießen, bevor du die TableSpaces kopieren kannst ),

a) was ist beim Backup-Restore oder Datenbank aushängen und wieder einhängen, gefährlich?
b) "SQL Svr abschießen" wie geht das ? der Server läuft dabei doch weiter
c) was sind "TableSpaces kopieren" ?

Zitat:

Warum greifst du nicht einfach von zu Hause auf die DB zu?

wenn das mal nicht gefährlich ist :wink:
aber ne weitere alternative

[Robert_G]

Zitat:

Zitat von trifid

@Robert_G,

Zitat:

das ist nicht nur gefährlich (du musst ja erst den SQL Svr abschießen, bevor du die TableSpaces kopieren kannst ),

a) was ist beim Backup-Restore oder Datenbank aushängen und wieder einhängen, gefährlich?
b) "SQL Svr abschießen" wie geht das ? der Server läuft dabei doch weiter
c) was sind "TableSpaces kopieren" ?

• a+b) Datenbank aushängen und wieder einhängen :arrow: das meine ich mit abschießen ;)
  IMHO sollte eine DB nur dann heruntergefahren werden, wenn es sich nicht verhindern lässt.
• c) Da du in der DP viele Antworten zu meheren DBMS gibst, müsstest du das eigentlich wissen. :roll:
  TableSpace -> Datei die mehrere Tabellen und andere DB-Objekte enthält.

Zitat:

Zitat von trifid

Zitat:

Warum greifst du nicht einfach von zu Hause auf die DB zu?

wenn das mal nicht gefährlich ist :wink:
aber ne weitere alternative

Keine weitere Alternative, es ist die einzige, die sich in der Praxis als machbar herausgestellt hat.
Es sollte IMHO heutzutage _normal_ sein sich von zu Hause per VPN auf das Firmennetz anmelden zu können. -> Nicht nenneswert unsicherer als eine Anmeldung innerhalb des Firmengebäudes.

[Bernhard Geyer]

Zitat:

Zitat von Robert_G

Datenbank aushängen und wieder einhängen :arrow: das meine ich mit abschießen ;)
IMHO sollte eine DB nur dann heruntergefahren werden, wenn es sich nicht verhindern lässt.

Da die Datenbank noch in der Entwicklung ist, seh ich das als Alternative an. Für eine Produktivdatenbank ist das sicherlich nicht geeignet

Zitat:

Zitat von Robert_G

Keine weitere Alternative, es ist die einzige, die sich in der Praxis als machbar herausgestellt hat.
Es sollte IMHO heutzutage _normal_ sein sich von zu Hause per VPN auf das Firmennetz anmelden zu können. -> Nicht nenneswert unsicherer als eine Anmeldung innerhalb des Firmengebäudes.

Man könnte ja auch eine Replikation einrichten. Somit wird nicht permanent eine Verbindung benötigt, sondern einfach die DB einmal pro Tag synchronisieren. Dürfte sich jedoch nicht mehr die DB-Struktur ändern. (bzw. muß neu aufgesetzt werden).

[Peeters]

Das Thema scheint doch sehr komplex zu sein. Ich werde dann doch erst einmal die VPN Möglichkeit in betracht ziehen.

Vielen Dank