Albert, I'll stay with English so everyone on the list can follow...
You aked on Mon, 12 Jan 2004 16:04:03 +0100: > > when unflatting certain binary datas with "Unflatten fromString" (LV7) I > get an error msg window "Nicht gen�gend Speicher zum Abschlie�en dieser > Operation" (* not enough memory to close this operation). The error-output > of the vi is incorrect. > Does anybody know a workaround of that bug? Steven M gave you the hint to include a file version info with your files. This would have helped a lot and is a good idea for the future, but will not help you out of your actual problems. What you can do however is writing a transformation VI that is capabel of detecting all former file formats and transforms them to a unique new format including the version info. I'd suggest a kind of chained list or array of strings, containing flattened data. How can this transformation be done without running into that error? Just don't use unflatten from string, at least not as the version detector. You should instead cut parts out of your string that correspond to simple data types and cast them for testing purposes. The problem is that arrays and strings have a size in their data structure (refer to the apropriate AppNote) that may cause the allocation of huge amounts of memory if the wrong number is at a size's position in the unflattened string. If you cut just that number out of the string and cast it to a numeric you'll find if this has an apropriate value _before_ that error happens. > I have binary files with different versions of a certain datatype. When > loading a file, I try to unflatten the data using the newest dataversion. > If I get an error, I try the 2nd newest dataversion and so on until I found > the right datatype. This methode was ok up to LV6.01. > In LV7.0 the bug appears when I try to unflatten to the wrong datatype. My > datatype is an array of clusters of strings and numbers. Your solution as used until now is a kind of weak. There may exist situations where unflattenfromstring is working OK, but does not provide the proper data. A unique version info as the start of a file is always more reliabel. > NI knows the bug but has no patch or workaround. NI-service told me, to > wait for LV7.1, maybe mid of 2004, --- very �good� service. > This bug is a fatal problem for me, I cannot read many of my old measuring > datas under LV7.0. > If I dont find an solution, the consequence will be, I throw out LV7 and go > back to LV6.01. You know that all Newbies at NI (at least in Germany) start in the support team, dont you? Thats OK, as this way they learn the real world problems. But don't take 'em too seriously when they propose something in new versions, as they don't do devellopment (of LV or other core products). Maybe they even did not really understand your problem (yet). Contact me directly if you need further assistance. Mit freundlichen Gr��en! Greetings from Germany! -- Uwe Frenz ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr. Uwe Frenz Entwicklung getemed Medizin- und Informationtechnik AG Oderstr. 59 D-14513 Teltow Tel. +49 3328 39 42 0 Fax +49 3328 39 42 99 [EMAIL PROTECTED] WWW.Getemed.de
