Hallo.
Ich suche eine Web Anwendung mit der ich Seriennummern verwalten kann.
Also ich will zur Nummer 123456 wissen:
- Der Original käufer
- Wann gebaut
- Wann war das Teil wieder bei mir
- Wer hat es mir gesendet
- Was war dran
- Was wurde gemacht
- Dazu würde ich gerne Bilder Texte .. mit ablegen
Zur Zeit ist das alles auf Papier bzw steht auf der Rechnung.
Aber das ist auf dauer nicht so schön.
Kennt jemand so ein Projekt was man dazu nehmen kann?
VG, Dirk
Ich würde es mit einer Datenbank Lössen, mit Microsoft .NET Core ist so
was ganz schnell gemacht.
Schau mal auf Microsoft Virtual Academy da gibt es super Tutorials
dafür.
Excel und konsorten kann man durchaus dafür verweden, allerdings muss
man schon ziemlich fit in Excel sein um das vernünftig hinzukriegen.
Ich habe sowas ähnliches, hab mir einfach in sqlite eine einfache
Datenbank zusammengebaut. Es gibt auch ein vernünftige GUI für sqlite
http://sqlitebrowser.org/
Alternative mySQL oder mariadb mit phymysql.
Elela kenne ich und habe ich im Einsatz ist dafür aber auch nicht
wirklich geeignet.
Ich möchte mal sehen wie man unter Exel ein PDF, JPG und so weiter an
eine SN dran bekommt.
Ist aber auch egal weil das ganze so nicht auf einem Server läuft.
JIRA kenne ich nicht, werde ich mir mal ansehen.
Ist aber auf den 1. Blick eine aufgebohrtes Mantis oder Trac.
Mantis setze ich schon ein, ist für die SN Verwaltung aber auch nicht
gut.
Wahrscheinlich kommen im laufe der Zeit noch einige Anforderungen dazu.
In Summe kommst du dann besser bei weg, wenn du ein PHP Mysql Tutorial
durcharbeitest und dabei die Tabelle und die Seiten passend zu deiner
Seriennummerndatenbank anlegst.
Das kann ich zwar, aber warum das Rad mal wieder neu Erfinden.
Was erweitern wäre dann kein Problem, auch das dem Original Projekt dann
zur kommen zulassen.
So etwas sollte ja keine Einbahnstrasse sein.
Leider nichts was für meinen Fall gut wäre.
Wenn ich nichts finde werde ich wohl was selber schreiben.
Hätte ich mir gerne gespart.
Bis das fertig ist werde ich wohl das ganze in ein Wiki rein packen.
Sind bis jetzt zum Glück noch nicht viele "Geräte".
Ich mach das mit Bordmitteln von Linux.
Den Datenbestand halte ich in Verzeichnissen, da kann ich dann alles
ablegen, was ich möchte. Die Stammdaten dazu liegen jeweils im
Verzeichnis als "index"-Textdatei, Format ganz simpel an "cookie jar"
angelehnt:
1
Kunde: Blabla
2
Datum: Blabla
3
%
4
Freitext
5
bla
6
bla
7
bla
Suchen mit "find", den Rest machen ein paar kurze Shell-Skripte.
Das ist jetzt insgesamt seit Jahren angenehmer und flexibler zu
benutzen, als jede Datenbank...
>Bis das fertig ist werde ich wohl das ganze in ein Wiki rein packen.
Dann schlage ich vor: Am 23.8.2027 treffen wir uns hier wieder und
feiern das 10 jährige bestehen des provisorischen Wikis.
Die Aufgabe war
> Ich suche eine Web Anwendung mit der ich Seriennummern verwalten kann.
diese Antwort dazu
MaWin (Gast)
Datum: 23.08.2017 15:22
> Tabellenkalkulation?
finde ich völlig ausreichend und passend.
Um wieviele Gertäte geht es eigentlich so pi mal Daumen?
Bei mir läuft das auch mit Openoffice aka Tabellenkalkulation ähnlich
Excell, dann noch DateiOrdner für die Projekte wo der Rest an Bildern
Daten drin ist.
Aber jeder wie er will und mag.
Wenn man zu viel Freizeit hat und aus jedem Fliegenschiß ein Projekt
machen muß, dann ist die eigentl. Arbeit wohl nicht so anspruchsvoll?
An alle die hier dauernd Excel vorschlagen:
Schauen wir uns mal die Funktion an → "Tabellenkalkulation"
Es ist also ein Programm für Tabellen und Kalkulation. Was glaubt ihr
sollte man nun mit diesem Programm machen und wozu ist es nicht gedacht.
Tipp: Tabellenkalkulationen sind KEINE Datenbanken!
Das Ganze soll etwas laengerfroistiges werden... Dann eher keine Excel
oder so. Lieber eine einfache Datenbank auf einem MySQL Server.
Bedienung mit phpMyAdmin. Da weiss man, dass es auch in 10 Jahren noch
laeuft.
Dirk schrieb:> Ich suche eine Web Anwendung mit der ich Seriennummern verwalten kann.>> Also ich will zur Nummer 123456 wissen:> - Der Original käufer> - Wann gebaut> - Wann war das Teil wieder bei mir> - Wer hat es mir gesendet> - Was war dran> - Was wurde gemacht> - Dazu würde ich gerne Bilder Texte .. mit ablegen> [...]> Kennt jemand so ein Projekt was man dazu nehmen kann?
JSON als Datenformat, Elasticsearch als Datenspeicher, eine Webanwendung
in einer beliebigen Sprache als Frontend. Elasticsearch hat dabei den
Vorteil, daß es Dokumente (Datenblätter, anyone?) indexieren kann und
darüber gleich noch diverse schnelle Volltext-Suchmöglichkeiten mit
Scoring bietet.
Dirk schrieb:> Elela kenne ich und habe ich im Einsatz ist dafür aber auch nicht> wirklich geeignet.
Ich habe es vorgeschlagen, weil ich beim letzten überfliegen gesehen
habe, dass es unter Projekt - Geräte und darunter auch Einzelgeräte mit
Seriennummer und so gibt.
Aber scheinbar ist dieser Bereich noch nicht so fertig, dass man ihn
nutzen kann.
Vielleicht kannst du im EleLa Thread den Markus mal fragen bevor du
selbst was neu erfindest ;-)
Schreiber schrieb:> Microsoft Access>> Funktioniert, kann alles was gefordert wird und man kommt schnell zu> einem ansprechenden Ergebnis...
Und darf u.U. bei jeder neuen W$-Version dran rumbasteln, um es
lauffähig zu halten.
tgby6hnujm
@Dirk:
suchst Du privat oder für die Firma?
Wir haben in der Firma eine webbasierte Eigenentwicklung und wird an
mehreren Standorten genutzt und synchronisiert. Verfolgung von
Lieferungen, Seriennummern, Fehlermeldungen, etc. Komplette
Logistikkette für das Maintenance von Ausbildungsmitteln.
Momentan wird das Tool noch nicht aktiv in die Privatwirtschaft
vermarktet. Aber da es Überlegungen hierzu gibt, wäre es eine Option.
Soll schon für meine Firma (UG) sein. Privat verkaufe ich nichts.
Bis jetzt ist es noch recht klein und die Stückzahlen sind mehr als gut
überschaubar. Aber wie immer soll es besser werden, sonst bräuchte man
ja nichts starten.
Eine WEB / DB Anwendung soll es halt sein damit ich in 10 Jahren und 8
Betriebssystem Versionen später noch was damit anfangen kann.
Von meinem jetztigen Geldgeber kenne ich es nur zu gut:
Software die nur unter XP aber nicht unter WIN10 arbeitet.
Drucker nur mit XP Treiber und die waren mal extrem teuer (>6K).
Wird also ein neues Projekt, schade.
Dirk
Dirk schrieb:> Also ich will zur Nummer 123456 wissen:> - Der Original käufer> - Wann gebaut> - Wann war das Teil wieder bei mir> - Wer hat es mir gesendet> - Was war dran> - Was wurde gemacht> - Dazu würde ich gerne Bilder Texte .. mit ablegen
Das hört sich relativ simpel an. Es müsste möglich sein jemanden zu
finden der sowas binnen einer Woche von Null aus auf die Beine stellen
kann. Wenn derjenige wirklich gut ist macht er es in einer Nacht.
Nun wo ist der EINE, der am besten daraus ein Opensouce Projekt macht?
Ich brauche garantiert mindestens eine Woche, so gut ist mein PHP dann
doch nicht.
Erstmal: Eine Excel-Tabelle ist durchaus geeignet, als einfache
Datenquelle mit Filterfunktionen zu dienen und für den Einstieg in die
Datenverarbeitung ( ca. 1000 Datensätze ) durchaus angebracht.
Für ein größeres Datenverarbeitungs-Projekt muss man schon einige
Planungs- und Entwicklungsarbeit leisten.
Hier nur die Stichwörter:
Datenmenge, Datenstruktur, Stamm und Bewegungsdaten, eindeutiger Index,
Abfragemöglichkeiten, Verwaltung der Zusatzdaten in Bild- oder
Textdateien
Also, wenn es schnell gehen muss, kann man durchaus mit zwei
Excel-Tabellen, eine für die Stamm- und eine für die Bewegungsdaten
anfangen, die z. B. über den Index "Gerätenummer" verbunden sind. Diese
Tabellen kann man später über ODBC-Treiber in beliebige Datenbanken
importieren.
Eine Woche geht bei so etwas schnell drauf, bei der Umsetzung kommen
einem ja außerdem laufend neue Ideen - letztendlich wird so etwas dann
eine Dauer-Baustelle. PHP, Access, .NET etc. können einem da schnell
viel Zeit stehlen.
Excel ist sicher auch nicht ideal - Grafiken kann man nicht gut einem
Datensatz zuordnen. Jira ist ein mächtiges System, da hat man die Woche
schon rum, bis es konfiguriert ist.
Ich kenne leider auch nichts Fertiges, aber für so eine einfache
Datenbank würde ich mir mal Filemaker näher ansehen.
Ansonsten würde ich auch eher ein bis zwei Tage spendieren und nach Open
Source Gerätemanagement / Device Management suchen, das lohnt sich
sicher eher.
Dirk schrieb:> Ein Student kostet mich aber Geld.> Was ich mir dann mit eigener Arbeitskraft lieber selber verdiene bzw> nicht ausgeben muss.
Na dann...
tgby6hnujm
Hallo Dirk,
da hilft nur eine Datenbank. Als DOS-Mensch würde ich dBase/Clipper
empfehlen. ;-) Also SQL, Access o. ä. Um etwas anderes wirst du nicht
herumkommen. Alles andere ist Pfusch. Mache dir nur klar, dass das
Lernen einer Datebanksprache genau so mühsam ist wie das Lernen
einer anderen Programmiersprache!
Beschäftige dich mal mit Normalformen von Datenbanken.
Infos dazu gibt es im Net ohne Ende.
73
Wilhelm
Wenn du nach "datenbanken online" suchst, findest du Testobjekte.
Eventuell ist Auftragsverwaltung oder Inventarliste geeignet für deinen
Zweck. Die Vorlagen kann man auch anpassen oder selbst eine eigene
Datenbank-Vorlage erstellen.
Zumindest hast du dann professionelle Beispiele zur Orientierung.
Tabellencalc dürfte das Einfachste und Schnellste sein und
übersichtlicher als die dateisystembasierte Lösung ist es auch.
Für sowas Primitives würde ich auch kein DB-Projekt starten, völliger
Overkill, auch wenns theoretisch nicht der reinen Lehre entspricht.
Wenn das mal zu umfangreich wird kann man die Daten ganz leicht aus
Excel in eine DB importieren oder die Exceltabelle selbst als DB per
ODBC bereitstellen und dann auch ein Webfrontend voranklemmen wenn
erwünscht.
Da das aber eh nur auf dem eigenen Rechner läuft, wie ich herauslese,
reicht eine Exceltabelle.
Wilhelm S. schrieb:> Also SQL, Access o. ä. Um etwas anderes wirst du nicht> herumkommen. Alles andere ist Pfusch.
Also wer MSSQL oder Access vorschlägt, sollte mit Äußerungen zu "Pfusch"
ganz ruhig sein.
T.roll schrieb:> Also wer MSSQL oder Access vorschlägt, sollte mit Äußerungen zu "Pfusch"> ganz ruhig sein.
Access funktioniert zumindest und führt schnell zu einer brauchbaren und
benutzerfreundlichen Lösung. Nichtalles ist so schlecht wie sein Ruf.
Wer will kann natürlich auch auf SAP oder Oracle setzen, die verkaufen
einem sicher auch was passendes.
Lude Kalle schrieb:> Da das aber eh nur auf dem eigenen Rechner läuft, wie ich herauslese,> reicht eine Exceltabelle.
Dann solltest Du nochmal lesen ...
Dirk sprach von "Eigener Server", ein kleiner aber feiner Unterschied.
Und insbesondere in Verbindung mit "Soll schon für meine Firma (UG)
sein" liegt die Vermutung ziemlich nahe, daß da gegebenenfalls auch
mehrere Leute gleichzeitig drauf zugreifen. Für sowas ist Excel absolute
unbrauchbar, selbst wenn man es als Frontend für eine externe DB
vergewaltig. Und Access ist nicht viel besser (außer vielleicht als
Frontend). Sqlite passt ebenfalls nicht.
Diverse brauchbare DB wurden ja schon genannt. Bei MySQL hätte ich
persönlich allerdings Bauchschmerze, die Lizenzprobleme scheinen zwar
schon ne Weile vorbei, aber wenn man einmal auf die Nase gefallen ist
wird man das ungute Gefühl halt so schnell nicht mehr los.
Mein Favorit wäre PostgreSQL. Für die von Dirk erwähnten Blobs könnte
man das auch noch mit dem Vorschlag von sheevaplug kombinieren:
https://github.com/Mikulas/pg-es-fdw
FDW sind schon eine feine Sache:
https://wiki.postgresql.org/wiki/Foreign_data_wrappers
Zu einem Frontend käme man relativ einfach mit Open/LibreOffice.
Allerdings auch hier nicht durch Mißbrauch der Tabellankalkulation,
sondern indem man das Datenbankmodul benutzt (mit externem Server). Muß
man dann allerdings auf jedem Client installieren, ein Webinterface ist
da komfortabler. Und mit den Blobs könnte es auch problematisch werden.
Aber um am Anfang mal schnell ein paar Eingebemasken zu bauen oder ein
paar Reports zu bekommen ist es ganz brauchbar.
Schreiber schrieb:> Wer will kann natürlich auch auf SAP oder Oracle setzen, die verkaufen> einem sicher auch was passendes.
Mann muss für solchen Standardkram heutzutage überhaupt keine Software
mehr kaufen. Die meisten Datenbanken sind freie Software und die meisten
Programmiersprachen, Interpreter, Compiler, IDEs ebenso.
Man muss sich schon arg Mühe geben da was kostenpflichtiges zu finden
und wenn man tatsächlich durch Zufall was findet dann muss man sich noch
mehr Mühe geben zu begründen warum das für diesen Zweck (oder überhaupt
irgend einen Zweck) gerechtfertigt sein sollte.
Ich würd mir für den Zweck des OP schnell was mit Lazarus und MySQL oder
Firebird zusammenklicken.
guest schrieb:> Bei MySQL hätte ich> persönlich allerdings Bauchschmerze, die Lizenzprobleme scheinen zwar> schon ne Weile vorbei, aber wenn man einmal auf die Nase gefallen ist> wird man das ungute Gefühl halt so schnell nicht mehr los.
Deswegen haben sich auch viele Entwickler abgewandt und MariaDB
gegründet. Ist auch bei den meisten Distributionen schon der Standard.
Schreiber schrieb:> Access funktioniert zumindest und führt schnell zu einer brauchbaren und> benutzerfreundlichen Lösung. Nichtalles ist so schlecht wie sein Ruf.
Aber hat immer noch das Problem:
tgby6hnujm schrieb:> Und darf u.U. bei jeder neuen W$-Version dran rumbasteln, um es> lauffähig zu halten.>
tgby6hnujm
guest schrieb:> Lude Kalle schrieb:>> Da das aber eh nur auf dem eigenen Rechner läuft, wie ich herauslese,>> reicht eine Exceltabelle.>> Dann solltest Du nochmal lesen ...> Dirk sprach von "Eigener Server", ein kleiner aber feiner Unterschied.> Und insbesondere in Verbindung mit "Soll schon für meine Firma (UG)> sein" liegt die Vermutung ziemlich nahe, daß da gegebenenfalls auch> mehrere Leute gleichzeitig drauf zugreifen. Für sowas ist Excel absolute> unbrauchbar, selbst wenn man es als Frontend für eine externe DB> vergewaltig. Und Access ist nicht viel besser (außer vielleicht als> Frontend). Sqlite passt ebenfalls nicht.>
Dann solltest Du nochmal lesen ...
kleine Fa., keine EDV(-Abt.), Anfangsdaten auf Papier?
ODBC-Treiber setzt SQL an Excel ab, d. h. server- und webfähig
PHPexcel macht alles, d. h. server- und webfähig
Excel bindet direkt HTML-Tabellen ein, d.h. webfähig
Man kann natürlich mit Kanonen auf Spatzen schießen und eine DB für 1
Mio. Datensätze vorbereiten.
Da grundsätzliche Angaben fehlen (s. o.), kann man hier nur rätseln, was
der TO wirklich braucht. So 200 bis 500 Blatt würde ich einfach mit OCR
scannen und dann im Text suchen.
Für so etwas nimmt man eine Datenbank wie z.B. PostgreSQL, MySQl,
Firebird oder was es sonst so noch gibt. Die Datenbank läuft dann auf
einem Server Deiner Wahl.
Als Frontend kann man erst mal ein Datenbanktool aus einem Officepaket
(MS Access, Open/Libreoffice Base, Lotus Approach ....) nehmen. Die
können alle auf verschiedene externe Datenbanken zu greifen und diese
als Datenquelle nutzen. Vorteil dieser Lösung man hat sich relativ
schnell eine GUI zusammengebaut. Ich habe mir mal vor langer Zeit mit
Lotus Approach einige Masken für diverse Sachen zusammen gebastelt
(Kundenverwaltung, Lagerverwaltung, Auftragsverwaltung,
Reisekostenabrechnung). Ich hatte seinerzeit die Borlanddatenbank
benutzt. Der Kram läuft heute noch.
Wenn man dann Zeit und Lust hat kann man sich ja mit der
Programmiersprache seiner Wahl was eigenes zusammen basteln.
Oder schau doch mal hier https://dadabik.com. Ist zwar nicht umsonst
aber 45€ für die Basisversion (die wahrscheinlich das kann was Du
brauchst) ist OK.
So angeblich kann man so was in der Art doch mit EleLa machen.
Würde ich gut finden da ich EleLa schon benutze.
Wenn nicht:
Mein Apache Server hat eine DB und damit kann ich umgehen.
Nur mein PHP ist halt heute nicht mehr so gut wie vor Jahren.
Darum würde ich etliche Tage brauchen um so was zu schreiben.
@Claus H.
Papier ist auch heute noch ein gern gesehenes Objekt.
VG, Dirk
Knallbonbon schrieb:> SAP Demoversion
Wer sich einmal in die Fänge von SAP begibt, kommt da nie mehr raus.
Dirk schrieb:> Darum würde ich etliche Tage brauchen um so was zu schreiben.
Naja wir diskutieren hier auch schon seit Tagen. So groß und komplex
wird dein Programm ja nicht. Das solltest du schaffen.
@Dirk:
Na, ja, das Papier - Fluch oder Segen? :-)
Für Apache mit PHP und MySQL (jetzt MariaDB) habe ich 2004 ein
Kundenmodul geschrieben. Die Kundendaten hatten eine feste, vorgegebene
Struktur. Es ging nur darum CSV (aus Excel, DBF oder sonstwo)
automatisch in MySQL zu importieren und die geänderten Kundendaten
wieder zu CSV exportieren. Das Miniprojekt hatte ca. 5 kB Code.
Meine Erfahrung ist, dass die Datenstruktur, der eindeutige Index und
ein zusätzliches freies Textfeld für spezielle Selektionen im Laufe der
Jahre wichtig sind.
Ach, so, das Allerwichtigste hätte bald vergessen: Spiegelserver oder
Datensicherung (MySQLDumper per Cronjob)!
Du hast eine Nummer (Seriennummer), und willst dazu beliebige
Informationen zeitlich geordnet und kategorisiert abspeichern.
Das ist genau das, was ein Ticket-System tut. Statt "Support-Anfragen"
besteht ein Ticket bei dir halt aus einer Seriennummer.
Vorteil: Solche Systeme gibt es schon, sie lassen sich wunderbar
automatisieren (E-Mail-Integration etc.) und sie sind getestet.
Dirk schrieb:> Wenn nicht:> Mein Apache Server hat eine DB und damit kann ich umgehen.> Nur mein PHP ist halt heute nicht mehr so gut wie vor Jahren.> Darum würde ich etliche Tage brauchen um so was zu schreiben.
Wenn Dir PHP nicht liegt nimm halt was anderes. Von Python über Java,
C/C++ bis Javascript ist so ziemlich alles möglich.
Dirk schrieb:> Mein Apache Server hat eine DB und damit kann ich umgehen.> Nur mein PHP ist halt heute nicht mehr so gut wie vor Jahren.> Darum würde ich etliche Tage brauchen um so was zu schreiben.
Ihr seid ja immer noch mit Euren Datenbanken dran. Keine Ahnung, warum
man für sowas eine Datenbank haben wollen sollte, aus meiner Sicht ist
das der totale Overkill. Denn hier geht es nicht um
Businesstransaktionen, sondern nur um das einfache Speichern und Abrufen
strukturierter Daten. Dabei sind Multiversion Concurrency Control,
Referentielle Integrität, Transaktionale Ssicherheit oder
Write-Ahead-Logging -- also all das, was klassische RDBMS aus- und so
teuer macht -- vollkommen überflüssig, IMHO.
Aus Spaß an der Freude habe ich mich also mal ein paar Stündchen
hingesetzt (um genau zu sein, etwa vier) und einen kleinen Prototypen
geschrieben, der im Anhang zu finden ist. Da weder Datenbanken noch
Tabellenkalkulationen so etwas wie Attachments von Bildern oder
Datenblättern korrekt unterstützten, habe ich das einstweilen
ausgelassen... YMMV.
Sheeva P. schrieb:> Ihr seid ja immer noch mit Euren Datenbanken dran. Keine Ahnung, warum> man für sowas eine Datenbank haben wollen sollte, aus meiner Sicht ist> das der totale Overkill.
Ich bezweifle daß es in irgendeiner Hinsicht einfacher, besser oder
pflegeleichter wird wenn man krampfhaft versucht die Datenbankschicht
komplett selbst zu zusammenzuhacken anstatt wie von Dir abgelehnt
einfach eine fertige DB zu nehmen.
Bernd K. schrieb:> Ich bezweifle daß es in irgendeiner Hinsicht einfacher, besser oder> pflegeleichter wird wenn man krampfhaft versucht die Datenbankschicht> komplett selbst zu zusammenzuhacken anstatt wie von Dir abgelehnt> einfach eine fertige DB zu nehmen.
Äh, entschuldige, aber ich nehme eine fertige DB -- nur daß es sich
dabei nicht um eine klassische SQL-Datenbank, sondern um Elasticsearch
handelt.
Das Ding wird sowieso nie fertig. Wer über sowas Triviales erst ne
ellenlange Diskussion lostreten muss und für alles ne Ausrede hat (kein
Geld für Studenten, mein PHP ist eingerostet,...), das wird
erfahrungsgemäss in 5 Jahren immer noch nicht fertig sein, da immer noch
überlegt wird was das Beste Tool, DB, Sprache, Server, ... sein wird.
Sowas kloppt man in einem Vormittag zusammen, was man am besten kann und
was schon installiert ist und dann ist das erledigt.
@Altenpfleger
Es ist schön das DU das in einem Vormittag schreiben kannst.
Kannst es ja machen und beweisen das Du darin ein super Kerl bist.
Ich brauche da halt erheblich länger, leider.
Ich hatte für sowas ja auch etwas gesucht was fertig ist und was man
leicht anpassen könnte. Selber schreiben ist halt, wenn man lange nichts
in dem Bereich gemacht hat, recht schwer.
Ich bin dran (nebenbei), aber es geht halt nur langsam vorran.
VG, Dirk
Hallo zusammen.
@Altenpfleger
> Es ist schön das DU das in einem Vormittag schreiben kannst.
Du hast Recht Dirk.
So etwas erledigt man nicht zwischen Suppe und Kartoffeln.
> Ich brauche da halt erheblich länger, leider.> Selber schreiben ist halt, wenn man lange nichts> in dem Bereich gemacht hat, recht schwer.
Kann man (wieder) lernen; 'Tel Aviv, so ist das Leben'.
> Das Ding wird sowieso nie fertig.
So ein Quatsch, der Leidensdruck muss nur gross genug
sein. ;-)
Ich weiss, wovon ich spreche:
Ca. 250000 Zeichen Quellcode, ca. 150000 Datensätze mit allem
Schnick und Schnack; vor allem mussten die Preise stimmen.
Ich hätte heute auch nach mehr als 20 Jahren Probleme, mit
meinem Quellcode klar zu kommen, obwohl ich nie mit
Kommentaren gespart habe.
73
Wilhelm
Zeno schrieb:> Ist zwar nicht umsonst> aber 45€ für die Basisversion (die wahrscheinlich das kann was Du> brauchst) ist OK.
Eigentlich ist das schon kostenlos - erst ab einer bestimmten Version
haben die Entwickler das Kostenpflichtig gemacht...
Mit etwas suchen findet man die sicher noch. Funktioniert super und die
bezahlten neuen features bracuht man eigentlich nicht.
