Filemaker

Posts 1-7 of 7

Carsten Reimer
The company name is only visible to registered members.

Verteiltes Entwicklen mit FM
Hallo,

wir stehen vor der Aufgabe in Zukunft eine FM-Anwendung mit drei Leuten anstelle von bislang einem weiterzuentwickeln.

Das macht die bisherige Vorgehensweise, nämlich Updates und Änderungen direkt im Live-System (Filemaker Server 9) vorzunehmen, nicht mehr praktikabel.

Uns schwebt sow etwas wie ein Entwicklungs- und ein Livesystem vor, wo man dann die Daten vom Live- ins Entwicklungssystem zurückspielen kann und umgekehrt veränderte Logik und Layouts vom Entwicklungssystem ins Livesystem ausspielen kann.

Geht sowas in Filemaker und wenn ja wie? Oder gibt es in FM andere Ansätze der verteilten Entwicklung?

Mit drei Leuten direkt im Livesystem zu ändern ist zumindest keine Option.

Vielen Dank für alle Tips

mit freundlichen Grüßen

Carsten Reimer
- 24 Jan 2011, 3:33 pm
Carsten Reimer wrote: > Hallo, > > wir stehen vor der Aufgabe in Zukunft eine FM-Anwendung mit drei > Leuten anstelle von bislang einem weiterzuentwickeln. > > Das macht die bisherige Vorgehensweise, nämlich Updates und > Änderungen direkt im Live-System (Filemaker Server 9) vorzunehmen, > nicht mehr praktikabel. > > Uns schwebt sow etwas wie ein Entwicklungs- und ein Livesystem vor, > wo man dann die Daten vom Live- ins Entwicklungssystem zurückspielen > kann und umgekehrt veränderte Logik und Layouts vom > Entwicklungssystem ins Livesystem ausspielen kann. > > Geht sowas in Filemaker und wenn ja wie? Oder gibt es in FM andere > Ansätze der verteilten Entwicklung? > > Mit drei Leuten direkt im Livesystem zu ändern ist zumindest keine > Option. > > Vielen Dank für alle Tips > > > mit freundlichen Grüßen > > > Carsten Reimer
Thomas Hahn Premium Member
The company name is only visible to registered members.

Re: Verteiltes Entwicklen mit FM
hallo herr reimer,

es ist doch kein problem eine saubere updateroutine zu bauen, die alle daten aus der bestehenden db in die neue version updatet. wir machen das seit jahren und unsere kunden müssen nur angeben wo die alte version liegt.

entwickeln und live arbeiten ist übrigens auch möglich. sie müssen einfach nur innerhalb der datenbank eine doppelte logik haben, die sie wahlweise umstellen können. d.h. es gibt immer zwei tabellen statt einer, doppelte scripts statt einem, etc. wenn die entwicklungsscripts laufen, können sie diese dann in die livescripts reinkopieren.
und mit der korrekten abfrage beim login gehen ihre mitarbeiter in die live version, sie in die developer version.

mit herzlichen grüssen
thomas hahn
- 24 Jan 2011, 11:26 pm
Thomas Hahn wrote: > hallo herr reimer, > > es ist doch kein problem eine saubere updateroutine zu bauen, die > alle daten aus der bestehenden db in die neue version updatet. wir > machen das seit jahren und unsere kunden müssen nur angeben wo die > alte version liegt. > > entwickeln und live arbeiten ist übrigens auch möglich. sie müssen > einfach nur innerhalb der datenbank eine doppelte logik haben, die > sie wahlweise umstellen können. d.h. es gibt immer zwei tabellen > statt einer, doppelte scripts statt einem, etc. wenn die > entwicklungsscripts laufen, können sie diese dann in die livescripts > reinkopieren. > und mit der korrekten abfrage beim login gehen ihre mitarbeiter in > die live version, sie in die developer version. > > mit herzlichen grüssen > thomas hahn
Carsten Reimer
The company name is only visible to registered members.

Re^2: Verteiltes Entwicklen mit FM
Hallo Herr Hahn,

vielen Dank für Ihre schnelle Antwort.

Habe ich Ihren ersten Vorschlag richtig verstanden, daß man quasi die Logik in einer Kopie weiterentwickelt und das Live-Stellen dergestalt passiert, daß man die Daten aus dem Live-System in die Kopie mit der neuen Logik synct und diese dann an die Nutzer verteilt?

Bei Ihrem zweiten Vorschlag habe ich ein wenig Bauchschmerzen. Mir wäre es lieber, man könnte ganz unabhängig vom Live-System entwickeln und hat nicht beides zusammen in einer Datei.

Was ich gestern noch gefunden habe und was mir auf den ersten Blick sehr gefallen hat sind die 'separation models' (s. http://www.scribd.com/doc/1486699/FileMaker-Separation-Model...). Da gefällt mir besonders gut die Option #2, wo auf den Clients nur ein Interface-File liegt und auf dem Server das Daten-File.

Haben Sie oder hat jemand anders hier vielleicht Erfahrung mit diesen separation models, die er/sie mit mir teilen könnte?

Vielen Dank schon mal

mit freundlichen Grüßen

Carsten Reimer
- 25 Jan 2011, 08:15 am
Carsten Reimer wrote: > Hallo Herr Hahn, > > vielen Dank für Ihre schnelle Antwort. > > Habe ich Ihren ersten Vorschlag richtig verstanden, daß man quasi die > Logik in einer Kopie weiterentwickelt und das Live-Stellen dergestalt > passiert, daß man die Daten aus dem Live-System in die Kopie mit der > neuen Logik synct und diese dann an die Nutzer verteilt? > > Bei Ihrem zweiten Vorschlag habe ich ein wenig Bauchschmerzen. Mir > wäre es lieber, man könnte ganz unabhängig vom Live-System entwickeln > und hat nicht beides zusammen in einer Datei. > > Was ich gestern noch gefunden habe und was mir auf den ersten Blick > sehr gefallen hat sind die 'separation models' (s. > http://www.scribd.com/doc/1486699/FileMaker-Separation-Models). Da > gefällt mir besonders gut die Option #2, wo auf den Clients nur ein > Interface-File liegt und auf dem Server das Daten-File. > > Haben Sie oder hat jemand anders hier vielleicht Erfahrung mit diesen > separation models, die er/sie mit mir teilen könnte? > > Vielen Dank schon mal > > mit freundlichen Grüßen > > Carsten Reimer
Post visible to registered members
Thomas Hahn Premium Member
The company name is only visible to registered members.

Re^3: Verteiltes Entwicklen mit FM
hallo herr reimer,

die separation modelle sind zwar immer wieder schön gedacht, aber ich halte davon nichts. die gründe sind zu viele.
die idee bei den clients "nur" das interface zu haben und dann auf dem server die daten, sind auch nicht machbar. was ist wenn sie 70clients haben, dann gibt es also 70 interface dateien? und wie updaten sie diese?

wir sind dazu übergegangen, nur zwei dateien plus eine startdatei plus eine eigene druckengine einzusetzen und lösen alles über saubere updatescripts. das geht sehr schnell und beim updaten lassen sich ggf. auch inhalte automatisch updaten.

am ende kommt es immer auch darauf an wohin sie mit ihrer lösung wollen. wenn sie "nur" ein internes system benötigen, würde ich auch live im system entwickeln. wenn sie eine breite kundengruppe wollen, dann müssen sie updateroutinen entwickeln und die gesamte struktur von beginn an auf eine maximallösung hin andenken, auch z.b. was die gesamten feld- und tabellennamen angeht.

oder variante drei, sie kaufen eine "fast" fertige lösung die zu 90% das abdeckt was sie benötigen und bauen sich dann nur das dazu, was sie zusätzlich brauchen. der aufwand eine "grosse" datenbanklösung hochzuziehen ist eben auch nicht ohne.

mit freundlichen grüssen
thomas hahn
- 25 Jan 2011, 1:49 pm
Thomas Hahn wrote: > hallo herr reimer, > > die separation modelle sind zwar immer wieder schön gedacht, aber ich > halte davon nichts. die gründe sind zu viele. > die idee bei den clients "nur" das interface zu haben und dann auf > dem server die daten, sind auch nicht machbar. was ist wenn sie > 70clients haben, dann gibt es also 70 interface dateien? und wie > updaten sie diese? > > wir sind dazu übergegangen, nur zwei dateien plus eine startdatei > plus eine eigene druckengine einzusetzen und lösen alles über saubere > updatescripts. das geht sehr schnell und beim updaten lassen sich > ggf. auch inhalte automatisch updaten. > > am ende kommt es immer auch darauf an wohin sie mit ihrer lösung > wollen. wenn sie "nur" ein internes system benötigen, würde ich auch > live im system entwickeln. wenn sie eine breite kundengruppe wollen, > dann müssen sie updateroutinen entwickeln und die gesamte struktur > von beginn an auf eine maximallösung hin andenken, auch z.b. was die > gesamten feld- und tabellennamen angeht. > > oder variante drei, sie kaufen eine "fast" fertige lösung die zu 90% > das abdeckt was sie benötigen und bauen sich dann nur das dazu, was > sie zusätzlich brauchen. der aufwand eine "grosse" datenbanklösung > hochzuziehen ist eben auch nicht ohne. > > mit freundlichen grüssen > thomas hahn
Carsten Reimer
The company name is only visible to registered members.

Re^4: Verteiltes Entwicklen mit FM
Hallo Herr Hahn,

nun, das Ändern im Live-System halte ich mit drei Entwicklern wie bei uns für sehr fehleranfällig. Oder irre ich mich da?
Da kommt man sich doch, so könnte ich mir vorstellen, eher in die Quere als einem das lieb sein kann.

Wir haben ca. 50 interne Clients. Meine Vorstellung der Verteilung ist (und Ähnliches habe ich im Netz gelesen), daß man die Interfacedateien per Kopierroutinen auf z. B. Netzlaufwerke, auf die die Clients Zugriff haben, verteilt.

Oder evt, ließe sich auch über eine Startdatei so etwas machen? Davon habe ich noch nicht so viel Ahnung.

Eventuell könnte man die Interface-Datei ja auch auf dem Server belassen (so wie in Option #1 aus dem Link, den ich vorhin zitiert habe). Dann würde man das Verteilproblem umgehen.

Ich komme halt aus der Webentwicklung und von daher ist mir die Trennung von Daten und Logik/Layout (am Liebsten die beiden Letzteren auch nochmal getrennt) sehr entgegen.

Wir werden wahrscheinlich ausprobieren müssen, was sich für uns am besten machen läßt.

Alle bisherigen Tips waren im Hinblick darauf, was man ausprobieren kann, bereits sehr hilfreich.

Mit freundlichen Grüßen

Carsten Reimer
- 25 Jan 2011, 2:25 pm
Carsten Reimer wrote: > Hallo Herr Hahn, > > nun, das Ändern im Live-System halte ich mit drei Entwicklern wie bei > uns für sehr fehleranfällig. Oder irre ich mich da? > Da kommt man sich doch, so könnte ich mir vorstellen, eher in die > Quere als einem das lieb sein kann. > > Wir haben ca. 50 interne Clients. Meine Vorstellung der Verteilung > ist (und Ähnliches habe ich im Netz gelesen), daß man die > Interfacedateien per Kopierroutinen auf z. B. Netzlaufwerke, auf die > die Clients Zugriff haben, verteilt. > > Oder evt, ließe sich auch über eine Startdatei so etwas machen? Davon > habe ich noch nicht so viel Ahnung. > > Eventuell könnte man die Interface-Datei ja auch auf dem Server > belassen (so wie in Option #1 aus dem Link, den ich vorhin zitiert > habe). Dann würde man das Verteilproblem umgehen. > > Ich komme halt aus der Webentwicklung und von daher ist mir die > Trennung von Daten und Logik/Layout (am Liebsten die beiden Letzteren > auch nochmal getrennt) sehr entgegen. > > Wir werden wahrscheinlich ausprobieren müssen, was sich für uns am > besten machen läßt. > > Alle bisherigen Tips waren im Hinblick darauf, was man ausprobieren > kann, bereits sehr hilfreich. > > Mit freundlichen Grüßen > > Carsten Reimer
Carsten Reimer
The company name is only visible to registered members.

Re^4: Verteiltes Entwicklen mit FM
Hallo Herr Friedrich,

vielen Dank für Ihre wertvollen Hinweise.

In der Tat werden wir, so wir uns für ein separation model entscheiden, unsere jetzige Datenbank auftrennen müssen. Wir werden das wohl mal auf einer Entwicklungsmaschine ausprobieren und schauen, wie gut sich das machen läßt.

Ggf. kommen wir dann gerne auf Ihr freundliches Angebot zurück.

Einen Umstieg auf v11 haben wir sowieso schon ins Auge gefaßt.

Mit freundlichen Grüßen

Carsten Reimer
- 25 Jan 2011, 2:30 pm
Carsten Reimer wrote: > Hallo Herr Friedrich, > > vielen Dank für Ihre wertvollen Hinweise. > > In der Tat werden wir, so wir uns für ein separation model > entscheiden, unsere jetzige Datenbank auftrennen müssen. Wir werden > das wohl mal auf einer Entwicklungsmaschine ausprobieren und schauen, > wie gut sich das machen läßt. > > Ggf. kommen wir dann gerne auf Ihr freundliches Angebot zurück. > > Einen Umstieg auf v11 haben wir sowieso schon ins Auge gefaßt. > > Mit freundlichen Grüßen > > Carsten Reimer

Filemaker

Verteiltes Entwicklen mit FM

Re: Verteiltes Entwicklen mit FM

Re^2: Verteiltes Entwicklen mit FM

Re^3: Verteiltes Entwicklen mit FM

Re^4: Verteiltes Entwicklen mit FM

Re^4: Verteiltes Entwicklen mit FM