Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #231755 > unrolled thread

Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen

Back to article view | Back to de.sci.electronics

Contents

  Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Bjoern <tueftler1@freakmail.de> - 2017-09-05 00:09 +0200
    Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Edzard Egberts <news@edzeg.net> - 2017-09-05 08:00 +0200
      Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Heiko Lechner <no.spam.to.me@arcor.de> - 2017-09-05 10:38 +0200
        Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Edzard Egberts <news@edzeg.net> - 2017-09-05 11:08 +0200
          Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Frank Buss <fb@frank-buss.de> - 2017-09-05 14:39 +0200
            Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Edzard Egberts <news@edzeg.net> - 2017-09-05 15:35 +0200
              Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Frank Buss <fb@frank-buss.de> - 2017-09-05 15:51 +0200
                Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Edzard Egberts <news@edzeg.net> - 2017-09-05 16:04 +0200
                  Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2017-09-05 21:16 +0200
                    Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Edzard Egberts <news@edzeg.net> - 2017-09-06 18:10 +0200
                      Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Joerg <news@analogconsultants.com> - 2017-09-06 09:35 -0700
                        Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Bjoern <tueftler1@freakmail.de> - 2017-09-06 19:51 +0200
                          Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Joerg <news@analogconsultants.com> - 2017-09-06 11:15 -0700
      Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Bjoern <tueftler1@freakmail.de> - 2017-09-06 01:42 +0200
    Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Joerg <news@analogconsultants.com> - 2017-09-05 07:34 -0700
      Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Bjoern <tueftler1@freakmail.de> - 2017-09-06 01:48 +0200
        Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Joerg <news@analogconsultants.com> - 2017-09-06 07:41 -0700
          Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Michael Limburg <mlimb@gmx.de> - 2017-09-06 18:04 +0200
            Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Joerg <news@analogconsultants.com> - 2017-09-06 09:15 -0700
              Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Michael Limburg <mlimb@gmx.de> - 2017-09-06 18:23 +0200
                Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Bjoern <tueftler1@freakmail.de> - 2017-09-06 19:55 +0200
    Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Michael Limburg <mlimb@gmx.de> - 2017-09-06 18:04 +0200
      Re: Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen Bjoern <tueftler1@freakmail.de> - 2017-09-06 19:53 +0200

Page 1 of 2  [1] 2  Next page →

#231755 — Assembleon Cad2Cad-Programm kann eigene Projekte nicht öffnen

Hallo!

Ich habe ein Programm zu unserem Philips-Bestücker Namens Cad2Cad (v1.5).
Der Hersteller ist Assembleon.

Ich habe das Programm in einer VM unter WinXP am laufen.
Es funktioniert soweit alles ganz gut, wenn nicht das fehlerhafte Laden
der eigenen Dateien wäre.

Sobald ich das gerade aufgesetzte Projekt als .cad lade, fällt das
Programm auf die Nase und bringt folgende Fehlermeldung:
"Exception: EConvertError in module LoadMCAD.dll at 000067B2" .

Wenn ich versuche eine UFO-Datei, die ich gerade exportiert habe zu
öffnen kommt:
"Exception: EConvertError in module LoadUFOS.dll at 00006672" .

Ist hier zufällig jemand, bei dem das Programm heutzutage noch Projekte
laden kann?
Habe eine komplette Installation von Cad2Cad aufgespielt und hoffe mal
nicht, dass es ein Datenfehler in den Dateien ist.

Grüße erst einmal,
Björn

[toc] | [next] | [standalone]

#231759

Bjoern wrote:
> "Exception:
> EConvertError in module LoadMCAD.dll at 000067B2" .
> 
> Wenn ich versuche eine UFO-Datei, die ich gerade exportiert habe zu 
> öffnen kommt: "Exception: EConvertError in module LoadUFOS.dll at
> 00006672" .
> 
> Ist hier zufällig jemand, bei dem das Programm heutzutage noch
> Projekte laden kann? Habe eine komplette Installation von Cad2Cad
> aufgespielt und hoffe mal nicht, dass es ein Datenfehler in den
> Dateien ist.

Das ist eine Java-Exception in Folge eines Programmierfehlers - unter
C/C++ wäre das ein astreiner Absturz! Bei so einem Fehler kann man sich
eigentlich nur an den Hersteller wenden, da ist wohl eine v1.6 fällig.

[toc] | [prev] | [next] | [standalone]

#231767

Am 05.09.2017 um 08:00 schrieb Edzard Egberts:

>> Wenn ich versuche eine UFO-Datei, die ich gerade exportiert habe zu 
>> öffnen kommt: "Exception: EConvertError in module LoadUFOS.dll at
>> 00006672" .

> Das ist eine Java-Exception in Folge eines Programmierfehlers

Interessant.

[toc] | [prev] | [next] | [standalone]

#231769

Heiko Lechner wrote:
> Am 05.09.2017 um 08:00 schrieb Edzard Egberts:
> 
>>> Wenn ich versuche eine UFO-Datei, die ich gerade exportiert habe zu 
>>> öffnen kommt: "Exception: EConvertError in module LoadUFOS.dll at
>>> 00006672" .
> 
>> Das ist eine Java-Exception in Folge eines Programmierfehlers
> 
> Interessant.

Das lässt sich auch genauer formulieren:

In der dll LoadUFOS wurde ein Fehler erkannt und gemeldet (Exception =
Methode zur nicht lokalen Fehlerbearbeitung), aber nicht von der
"eigentlichen" Software (die diese Bibliothek aufruft) abgefangen,
sondern bis zur Oberfläche durchgereicht. Da geht also gründlich etwas
schief, denn wenn der Programmierer mit diesem Fehler gerechnet hätte,
wäre der intern bearbeitet und nicht als Fehler gemeldet worden.

"Java" ist dann auf Verdacht, könnte auch C++ oder eine andere
Programmiersprache sein, aber mir ist eben nur von Java bekannt, dass
eine nicht bearbeitete Exception gemeldet wird, statt zu einem
Programmabsturz zu führen.

[toc] | [prev] | [next] | [standalone]

#231777

On 09/05/2017 11:08 AM, Edzard Egberts wrote:
> "Java" ist dann auf Verdacht, könnte auch C++ oder eine andere
> Programmiersprache sein, aber mir ist eben nur von Java bekannt, dass
> eine nicht bearbeitete Exception gemeldet wird, statt zu einem
> Programmabsturz zu führen.

Gibt es auch in C++. Da es eine DLL ist, ist das auch wahrscheinlicher, 
wenn der Herrsteller nicht eins der Programme verwendet hat, was Java 
Klassen in DLLs verpacken kann.

Die Nummer "00006672" lässt sogar eher auf C++ schließen, da es dort 
gerne so überhaupt nicht hilfreiche Angaben gibt. In Java bekommt man 
den Typ der Exception, den Klassennamen, Zeilennummer wo es aufgetreten 
ist und einen kompletten Call-Stack.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

[toc] | [prev] | [next] | [standalone]

#231783

Frank Buss wrote:
> On 09/05/2017 11:08 AM, Edzard Egberts wrote:
>> "Java" ist dann auf Verdacht, könnte auch C++ oder eine andere 
>> Programmiersprache sein, aber mir ist eben nur von Java bekannt,
>> dass eine nicht bearbeitete Exception gemeldet wird, statt zu
>> einem Programmabsturz zu führen.
> 
> Gibt es auch in C++.

Nein, so nicht: Unter C++ kann man natürlich auch im Main-Loop alle
Exceptions abfangen und anzeigen, aber nur als letzten Schritt vor dem
Exit, weil ein C++-Programm mit nicht bearbeiteter, unbekannter
Exception in einem undefinierten Zustand ist und nicht weiter ausgeführt
werden sollte. Dass eine Software Fehler wirft und trotzdem weiter
läuft, kenne ich nur von Java. Da geht das wahrscheinlich wegen der
eingebauten Speicherverwaltung, unter C++ kann man nicht einfach mal
irgend ein Programmteil abwickeln.

[toc] | [prev] | [next] | [standalone]

#231787

On 09/05/2017 03:35 PM, Edzard Egberts wrote:
> Nein, so nicht: Unter C++ kann man natürlich auch im Main-Loop alle
> Exceptions abfangen und anzeigen, aber nur als letzten Schritt vor dem
> Exit, weil ein C++-Programm mit nicht bearbeiteter, unbekannter
> Exception in einem undefinierten Zustand ist und nicht weiter ausgeführt
> werden sollte. Dass eine Software Fehler wirft und trotzdem weiter
> läuft, kenne ich nur von Java. Da geht das wahrscheinlich wegen der
> eingebauten Speicherverwaltung, unter C++ kann man nicht einfach mal
> irgend ein Programmteil abwickeln.

Doch, das geht genauso in C++. Der Fehler trat beim Import auf. Man kann 
dort genauso ein try/catch um die Import-Anweisung schreiben, wie in der 
main-Funktion. Dann läuft das Programm nach einem fehlerhaften Import 
auch weiter. Da das hier eine "EConvertError" Exception war, ist das 
wahrscheinlich auch möglich, da nicht irgendein Speicherbereich ungültig 
überschrieben wurde o.ä., sondern es vermutlich nur Probleme bei der 
Erkennung des eigenen Formats gab, was kein gutes Licht auf die Software 
wirft. Und statt eine vernünftige Fehlermeldung zu generieren ("Typ 
Line3 nicht erkannt" oder so), hat der Programmierer einfach eine 
EConvertError-Exception geworfen.

In C++ kann man natürlich auch "catch (...)" schreiben (also tatsächlich 
mit den drei Pünktchen). Das fängt dann auch Null-Pointer Exceptions 
usw. ab. Aber da es in C++ keinen Speicherschutz wie in Java gibt, ist 
danach alle Hoffnung verloren (das Programm könnte also beliebige Daten 
von anderen Programmteilen überschrieben haben) und man sollte das 
Programm beenden.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

[toc] | [prev] | [next] | [standalone]

#231789

Frank Buss wrote:
> On 09/05/2017 03:35 PM, Edzard Egberts wrote:
>> Nein, so nicht: Unter C++ kann man natürlich auch im Main-Loop
>> alle Exceptions abfangen und anzeigen, aber nur als letzten Schritt
>> vor dem Exit, weil ein C++-Programm mit nicht bearbeiteter,
>> unbekannter Exception in einem undefinierten Zustand ist und nicht
>> weiter ausgeführt werden sollte. Dass eine Software Fehler wirft
>> und trotzdem weiter läuft, kenne ich nur von Java. Da geht das
>> wahrscheinlich wegen der eingebauten Speicherverwaltung, unter C++
>> kann man nicht einfach mal irgend ein Programmteil abwickeln.
> 
> Doch, das geht genauso in C++. Der Fehler trat beim Import auf. Man
> kann dort genauso ein try/catch um die Import-Anweisung schreiben,
> wie in der main-Funktion.

Nein, man *muss* den try um die Import-Anweisung legen, denn bis die
Exception im Main angelangt ist, kann schon der gesamte Import-Teil
abgewickelt sein. Das geht nur, wenn man genau weiß, wo der Fehler
herkommt und wie der zu beheben ist.

> Dann läuft das Programm nach einem fehlerhaften Import auch weiter.

Und gibt auch keine seltsamen Meldungen aus.

> In C++ kann man natürlich auch "catch (...)" schreiben (also
> tatsächlich mit den drei Pünktchen). Das fängt dann auch Null-Pointer
> Exceptions usw. ab. Aber da es in C++ keinen Speicherschutz wie in
> Java gibt, ist danach alle Hoffnung verloren (das Programm könnte
> also beliebige Daten von anderen Programmteilen überschrieben haben)
> und man sollte das Programm beenden.

Genau davon habe ich geredet.

[toc] | [prev] | [next] | [standalone]

#231816

Hallo Edzard,

Du schriebst am Tue, 5 Sep 2017 16:04:57 +0200:

[EConvertError]
...
> abgewickelt sein. Das geht nur, wenn man genau weiß, wo der Fehler
> herkommt und wie der zu beheben ist.

Vielleicht, indem die "Lokalisierung" des Systems von wahrscheinlich
Deutsch auf Englisch umgestellt wird?

-- 
-- 
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#231871

Sieghard Schicktanz schrieb:
> Hallo Edzard,
> 
> Du schriebst am Tue, 5 Sep 2017 16:04:57 +0200:
> 
> [EConvertError]
> ...
>> abgewickelt sein. Das geht nur, wenn man genau weiß, wo der Fehler
>> herkommt und wie der zu beheben ist.
> 
> Vielleicht, indem die "Lokalisierung" des Systems von wahrscheinlich
> Deutsch auf Englisch umgestellt wird?

Den Hinweis von Jörg fand ich genial, hat nur scheinbar nichts gebracht.

Allerdings ist es tatsächlich genau diese Art von Problem, auf die man
als Programmierer immer reinfällt - irgend eine Einstellung, die zwar
ein Kunde verwendet, die der Entwickler aber nicht vorhergesehen hat.

Oder ein Sonderzeichen, vielleicht hat sich Bjoern ja Björn geschrieben?

Für Datum und Zahlen kann man AFAIK in den meisten Betriebssystemen auch
getrennt von der Sprachen-Lokalisierung so Sachen wie das
Dezimaltrennzeichen einstellen, so etwas wäre auch möglich.

Aber ein Fehler ist es wahrscheinlich trotzdem, weil beim Import der
eigenen Dateien die gleichen Einstellungen wie beim Export benutzt
werden sollten.

@Björn: Die Datei schon mal mit Text- oder Hexeditor angeguckt? Manchmal
fallen einem dabei seltsame Sachen auf.

[toc] | [prev] | [next] | [standalone]

#231874

On 2017-09-06 09:10, Edzard Egberts wrote:
> Sieghard Schicktanz schrieb:
>> Hallo Edzard,
>>
>> Du schriebst am Tue, 5 Sep 2017 16:04:57 +0200:
>>
>> [EConvertError]
>> ...
>>> abgewickelt sein. Das geht nur, wenn man genau weiß, wo der Fehler
>>> herkommt und wie der zu beheben ist.
>>
>> Vielleicht, indem die "Lokalisierung" des Systems von wahrscheinlich
>> Deutsch auf Englisch umgestellt wird?
>
> Den Hinweis von Jörg fand ich genial, hat nur scheinbar nichts gebracht.
>
> Allerdings ist es tatsächlich genau diese Art von Problem, auf die man
> als Programmierer immer reinfällt - irgend eine Einstellung, die zwar
> ein Kunde verwendet, die der Entwickler aber nicht vorhergesehen hat.
>
> Oder ein Sonderzeichen, vielleicht hat sich Bjoern ja Björn geschrieben?
>
> Für Datum und Zahlen kann man AFAIK in den meisten Betriebssystemen auch
> getrennt von der Sprachen-Lokalisierung so Sachen wie das
> Dezimaltrennzeichen einstellen, so etwas wäre auch möglich.
>

Das ist auch ein guter Hinweis. NXP hat etwa die schlechte Angewohnheit, 
bei Bauteilnamen gelegentlich Kommata reinzusetzen wie z.B. bei 
"BSS123,215". Wenn die aus irgendeinem Gund mit in die Pick&Place Files 
geraten (sollten sie eigentlich nicht), dann kann es rumms machen.


> Aber ein Fehler ist es wahrscheinlich trotzdem, weil beim Import der
> eigenen Dateien die gleichen Einstellungen wie beim Export benutzt
> werden sollten.
>

Das hat Bjoern offenbar eingehalten und dennoch laedt es nicht korrekt.


> @Björn: Die Datei schon mal mit Text- oder Hexeditor angeguckt? Manchmal
> fallen einem dabei seltsame Sachen auf.
>

Auch den zugrundeliegenden XYRS File und die Netlist ansehen, die kann 
man rasch querlesen. Ich hatte mit Layoutern und Bestueckern schonmal 
Malessen, weil deren Software irgendein Zeichen nicht frass. Oder sie 
bekamen eine Meldung a la "Corrupt File", waehrend der hier sauber fluppte.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#231875

Hi Ihr.... ICH HABS, ICH HABS :D

Mir ist gerade eben aufgefallen, dass bei der Nutzenerstellung die von
der Software selbst eingetragenen Werte angemeckert werden.
Als ich dann die Punkte sah, dachte ich an das selbe wie Ihr grade eben
(Hab Euren Post aber erst jetzt entdeckt).

Habe mit dem Editor das exportierte File geöffnet und stumpf alle Kommas
mit Punkte gewechselt -> Es tut!

Witzig: Intern meckert die Software die Punkte in den Textfeldern an und
beim Laden meckert die Software dann die Kommas an, lach.

Genial.
Aber jOErg, das mit den Umlauten ist schon ein Krampf - Kenn ich ganz gut ;)

bjOErn

[toc] | [prev] | [next] | [standalone]

#231880

On 2017-09-06 10:51, Bjoern wrote:
> Hi Ihr.... ICH HABS, ICH HABS :D
>
> Mir ist gerade eben aufgefallen, dass bei der Nutzenerstellung die von
> der Software selbst eingetragenen Werte angemeckert werden.


Hier waere der Punkt, wo man die Programmierer dieser Software in den 
Burggraben tunken sollte. Nur ganz leicht, zur Laeuterung.


> Als ich dann die Punkte sah, dachte ich an das selbe wie Ihr grade eben
> (Hab Euren Post aber erst jetzt entdeckt).
>
> Habe mit dem Editor das exportierte File geöffnet und stumpf alle Kommas
> mit Punkte gewechselt -> Es tut!
>
> Witzig: Intern meckert die Software die Punkte in den Textfeldern an und
> beim Laden meckert die Software dann die Kommas an, lach.
>
> Genial.
> Aber jOErg, das mit den Umlauten ist schon ein Krampf - Kenn ich ganz gut ;)
>

Viele bei uns an der Westkueste schreiben meinen Namen mexikanisch, 
Jorge. Steht sogar so in einer meiner CAD Lizenzen.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#231822

Am 05.09.2017 um 08:00 schrieb Edzard Egberts:

> Das ist eine Java-Exception in Folge eines Programmierfehlers - unter
> C/C++ wäre das ein astreiner Absturz! Bei so einem Fehler kann man sich
> eigentlich nur an den Hersteller wenden, da ist wohl eine v1.6 fällig.
> 

Das werde ich wohl machen müssen.
Das Programm ist glaube von 2002.
Habe leider keine neuere Version im Netz finden können.
Aber bei dem Alter ist das ja auch nicht sooo verwunderlich.
Aber ob das damals schon Java war... Sieht von der GUI eher nicht so aus.

Björn

[toc] | [prev] | [next] | [standalone]

#231792

On 2017-09-04 15:09, Bjoern wrote:
> Hallo!
>
> Ich habe ein Programm zu unserem Philips-Bestücker Namens Cad2Cad (v1.5).
> Der Hersteller ist Assembleon.
>
> Ich habe das Programm in einer VM unter WinXP am laufen.
> Es funktioniert soweit alles ganz gut, wenn nicht das fehlerhafte Laden
> der eigenen Dateien wäre.
>
> Sobald ich das gerade aufgesetzte Projekt als .cad lade, fällt das
> Programm auf die Nase und bringt folgende Fehlermeldung:
> "Exception: EConvertError in module LoadMCAD.dll at 000067B2" .
>
> Wenn ich versuche eine UFO-Datei, die ich gerade exportiert habe zu
> öffnen kommt:
> "Exception: EConvertError in module LoadUFOS.dll at 00006672" .
>
> Ist hier zufällig jemand, bei dem das Programm heutzutage noch Projekte
> laden kann?
> Habe eine komplette Installation von Cad2Cad aufgespielt und hoffe mal
> nicht, dass es ein Datenfehler in den Dateien ist.
>

Zur Fehlermeldung kann ich nichts sagen, aber falls sich keine 
Datenrettung hinbekommen laesst: M.W. wurde Assembleon von Kulicke & 
Soffa gekauft. In der Hoffung, dass sie aeltere Anlagen und SW 
weiterpflegen, koenntest Du die vielleicht bitten, Dein Projekt 
probehalber zu laden. Dann weisst Du zumindest, ob der Defekt bei Deinen 
Daten oder der installierten Software liegt.

Unwahrscheinlich, waere aber ein Hingucken wert: EConvertError passieren 
in Buchhaltungs-Software schonmal, wenn auf dem Computer, wo die 
Software neu installiert wurde, das Datums- oder Zeitformat anders 
eingestellt ist als auf dem, wo die Daten erzeugt wurden.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#231823

Am 05.09.2017 um 16:34 schrieb Joerg:
> Zur Fehlermeldung kann ich nichts sagen, aber falls sich keine
> Datenrettung hinbekommen laesst: M.W. wurde Assembleon von Kulicke &
> Soffa gekauft. In der Hoffung, dass sie aeltere Anlagen und SW
> weiterpflegen, koenntest Du die vielleicht bitten, Dein Projekt
> probehalber zu laden. Dann weisst Du zumindest, ob der Defekt bei Deinen
> Daten oder der installierten Software liegt.Die Daten sind frisch auf
dem OS exportiert worden.
Das funktioniert auch soweit.
Problem ist nur, dass wenn ich danach noch etwas ändern möchte, es nicht
mehr im Programm machen kann - nur noch im Editor oder an der Maschine.


> Unwahrscheinlich, waere aber ein Hingucken wert: EConvertError passieren
> in Buchhaltungs-Software schonmal, wenn auf dem Computer, wo die
> Software neu installiert wurde, das Datums- oder Zeitformat anders
> eingestellt ist als auf dem, wo die Daten erzeugt wurden.
Das wäre damit ja dann eigentlich ausgeschlossen.
Interessanterweise kann das Programm zwar alles mögliche Exportieren,
aber bei jedem Import knallt es dann.

Komische Sache das, echt.

Grüße, Björn

[toc] | [prev] | [next] | [standalone]

#231866

On 2017-09-05 16:48, Bjoern wrote:
> Am 05.09.2017 um 16:34 schrieb Joerg:
>> Zur Fehlermeldung kann ich nichts sagen, aber falls sich keine
>> Datenrettung hinbekommen laesst: M.W. wurde Assembleon von Kulicke &
>> Soffa gekauft. In der Hoffung, dass sie aeltere Anlagen und SW
>> weiterpflegen, koenntest Du die vielleicht bitten, Dein Projekt
>> probehalber zu laden. Dann weisst Du zumindest, ob der Defekt bei Deinen
>> Daten oder der installierten Software liegt.Die Daten sind frisch auf
> dem OS exportiert worden.
> Das funktioniert auch soweit.
> Problem ist nur, dass wenn ich danach noch etwas ändern möchte, es nicht
> mehr im Programm machen kann - nur noch im Editor oder an der Maschine.
>

Wenn dies am gleichen PC passiert, sieht es nach Software Bug aus und 
wie Edzard schrieb, waere V1.6 faellig.

>
>> Unwahrscheinlich, waere aber ein Hingucken wert: EConvertError passieren
>> in Buchhaltungs-Software schonmal, wenn auf dem Computer, wo die
>> Software neu installiert wurde, das Datums- oder Zeitformat anders
>> eingestellt ist als auf dem, wo die Daten erzeugt wurden.
> Das wäre damit ja dann eigentlich ausgeschlossen.
> Interessanterweise kann das Programm zwar alles mögliche Exportieren,
> aber bei jedem Import knallt es dann.
>
> Komische Sache das, echt.
>

Nicht unbedingt. Solche Software wird nur fuer einen ganz kleinen Markt 
geschrieben. Das stecken die Firmen nicht beliebig viel in der 
Validation Phase. Einige sehr grosse Firmen tun das auch bei Software 
fuer die breite Masse nicht ...

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#231869

Joerg wrote:

> Wenn dies am gleichen PC passiert, sieht es nach Software Bug aus und
> wie Edzard schrieb, waere V1.6 faellig.

Nö

[toc] | [prev] | [next] | [standalone]

#231872

On 2017-09-06 09:04, Michael Limburg wrote:
> Joerg wrote:
>
>> Wenn dies am gleichen PC passiert, sieht es nach Software Bug aus und
>> wie Edzard schrieb, waere V1.6 faellig.
>
> Nö
>

Ich war mal davon ausgegangen, dass in der Zeit zwischen 
Datei-Erstellung und Lesen keine Formate geaendert wurden.

-- 
Gruesse, Joerg

http://www.analogconsultants.com/

[toc] | [prev] | [next] | [standalone]

#231873

Joerg wrote:

> On 2017-09-06 09:04, Michael Limburg wrote:
>> Joerg wrote:
>>
>>> Wenn dies am gleichen PC passiert, sieht es nach Software Bug aus und
>>> wie Edzard schrieb, waere V1.6 faellig.
>>
>> Nö
>>
> 
> Ich war mal davon ausgegangen, dass in der Zeit zwischen
> Datei-Erstellung und Lesen keine Formate geaendert wurden.

Irgendetwas in der Richtung wird's vermutlich sein. Leider
ist die Fehlermeldung zu unspezifisch, um dem OP einen
Fingerzeig zu geben.

MfG

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.sci.electronics

csiph-web