Blackfish - Zugriffe - max. User

[stahli]

Hallo alle,

was bedeutet denn genau User und Connections bei der (Blackfish-)Datenbank?

Die Prof-Variante ist auf 1 User und 4 Connections beschränkt.
Lege ich eine Datenbank im Serverexplorer von Prism an, kann ich auf diese schon nicht mehr direkt aus meinem Projekt zuglreifen ohne sie zuvor zu schließen...
Kann ich dann später einmal "MeinNetProgramm" 4 mal starten und von 4 Clients (über ein LAN) auf meine lokale Datenbank zugreifen?

Und was genau versteht man genau unter Blackfish Remote- und Local-Server?
Bisher interpretiere ich das so, dass es sich bei Blackfish-Remote-Servver um einen "im System installierten Blackfish-Datenbankserver" handelt (der in meinem Windows oder entfernt auf einem Webserver laufen kann und ein Blackfish-Local-Server meinem Projekt beiliegt und von diesem gestartet und genutzt wird.

Unterscheiden sich da die oben bereits angefragten User-und Connections-Einschränkungen?
Kann man dann auf eine Blackfish-Datenbank als "lokale Datenbank" über ein LAN zugreifen (also ohne auf allen 4 Rechnern Blackfish als Server fest zu installieren)?


Ich habe zwar schon Blackfish-Datenbanken erzeugt, aber die o.g. Zusammenhänge sind mir noch nicht klar geworden...


Stahli

[Elvis]

Zitat von stahli:

was bedeutet denn genau User und Connections bei der (Blackfish-)Datenbank?
Die Prof-Variante ist auf 1 User und 4 Connections beschränkt.

Du kanst nur einen User haben und der darf nur max. 4 Verbindungen auf einmal aufbauen.

Zitat:

Lege ich eine Datenbank im Serverexplorer von Prism an, kann ich auf diese schon nicht mehr direkt aus meinem Projekt zuglreifen ohne sie zuvor zu schließen...
Kann ich dann später einmal "MeinNetProgramm" 4 mal starten und von 4 Clients (über ein LAN) auf meine lokale Datenbank zugreifen?
Und was genau versteht man genau unter Blackfish Remote- und Local-Server?

Local heißt, dass du in deinem Prozes das DBMS hast. Während Remote für ein klassisches Szenario steht, in dem ein Serverprozess das DBMS enthält.

Vergleichbar mit Firebird embedded versus "richtiger" Server.

Wenn du ein reines .Net DBMS haben willst, dann schaue dir VistaDB an. Das hat keine drakonischen Einschränkungen was Connections und User angeht, und auch vom Funktionsumfang ist es nicht annähernd so traurig wie Blackfish.
Und da es ohne Lizenzen auskommt gibt es einen Single-Point-of-Failure weniger: Nämlich CodeGEARs selten dummes De-Aktivierungssystem, was mehr als genug Macken hat. Das letzte was du willst ist ein DBMS beim Kunden zu haben, das ein Totalversagen zeigt, weil CodeGEARs De-Aktivierung mal wieder Amok läuft.

Muss es kein reines .Net-DBMS sein, dann gibt es die üblichen Verdächtigen von SQLite, über Firebird bis hin zu MSSQL Everywhere.


Oh, und als Hinweis für zukünftige Postings: "Delphi Prism" ist keine Art des DB Zugriffs.
Sowas wäre zum Beispiel CodeGEARs dbExpress ADO.Net Provider, oder ODBC, oder was auch immer. Aber die verwendete Sprache sagt wohl kaum etwas über die Art des Zugriffes aus.

[stahli]

Zitat von Elvis:

Du kanst nur einen User haben und der darf nur max. 4 Verbindungen auf einmal aufbauen.

Ist klar. Aber was ist gemeint?
User ist bei mir nur sysdba. Verbindung ist nur durch ServerExplorer und dann durch mein Prism-Projekt hergestellt. Beim Starten des Projektes (compilieren) gibt es schon ein Problem. Das wäre ja aber erst die max. dritte Verbindung... Daher verstehe ich das nicht...

Zitat von Elvis:

Local heißt, dass du in deinem Prozes das DBMS hast. Während Remote für ein klassisches Szenario steht, in dem ein Serverprozess das DBMS enthält. Vergleichbar mit Firebird embedded versus "richtiger" Server.

Ha! Richtig gedacht!

Zitat von Elvis:

Wenn du ein reines .Net DBMS haben willst, dann schaue dir VistaDB an. Das hat keine drakonischen Einschränkungen was Connections und User angeht, und auch vom Funktionsumfang ist es nicht annähernd so traurig wie Blackfish.
Und da es ohne Lizenzen auskommt gibt es einen Single-Point-of-Failure weniger: Nämlich CodeGEARs selten dummes De-Aktivierungssystem, was mehr als genug Macken hat. Das letzte was du willst ist ein DBMS beim Kunden zu haben, das ein Totalversagen zeigt, weil CodeGEARs De-Aktivierung mal wieder Amok läuft.
Muss es kein reines .Net-DBMS sein, dann gibt es die üblichen Verdächtigen von SQLite, über Firebird bis hin zu MSSQL Everywhere.

Merke ich mir auf jeden Fall vor. Bin noch nicht sicher, was später mal zum Einsatz kommt.
Ein kleines Web-Projekt läuft momentan mit Blackfish. Ein .Net-Projekt soll wahrscheinlich mal mit ECO aufgebaut werden (teste ich gerade etwas...)

Zitat von Elvis:

Oh, und als Hinweis für zukünftige Postings: "Delphi Prism" ist keine Art des DB Zugriffs.
Sowas wäre zum Beispiel CodeGEARs dbExpress ADO.Net Provider, oder ODBC, oder was auch immer. Aber die verwendete Sprache sagt wohl kaum etwas über die Art des Zugriffes aus.

Ist klar.


Danke!

Stahli

[Elvis]

Zitat von stahli:

Zitat von Elvis:

Du kanst nur einen User haben und der darf nur max. 4 Verbindungen auf einmal aufbauen.

Ist klar. Aber was ist gemeint?
User ist bei mir nur sysdba. Verbindung ist nur durch ServerExplorer und dann durch mein Prism-Projekt hergestellt. Beim Starten des Projektes (compilieren) gibt es schon ein Problem. Das wäre ja aber erst die max. dritte Verbindung... Daher verstehe ich das nicht...

Zitat von Elvis:

Local heißt, dass du in deinem Prozes das DBMS hast. Während Remote für ein klassisches Szenario steht, in dem ein Serverprozess das DBMS enthält. Vergleichbar mit Firebird embedded versus "richtiger" Server.

Ha! Richtig gedacht!

Nur ein Prozess kann die DB auf einmal anfassen.

[Phoenix]

Zitat von stahli:

Ein .Net-Projekt soll wahrscheinlich mal mit ECO aufgebaut werden (teste ich gerade etwas...)

Ein gutgemeinter Rat: Lass die Finger von ECO.

Ich habe noch nie ein so extrem unflexibles, kompliziertes und langsames Framework gesehen wie ECO. SOlange Du alles im ECO-Style machst scheint alles okay -aber sobald Du auch nur ein Feature benötigst, das ECO nicht von Haus aus anbietet, bist Du zu 200% aufgeschmissen und es ist einfacher, alles ohne ECO neu zu machen als um ECO herum zu entwickeln und das Feature einzubauen. Es gibt leichtere und schmerzfreiere Arten ein Projekt gegen die Wand zu fahren als ECO dafür zu benutzen. Delphi 8 für .NET war so eine leichtere und schmerzfreiere Art.

Da ist z.B. das ADO.NET Entity Framework um längen flexibler (und schneller).