03-26-2022 12:15 PM
I am using LabVIEW 2019 running on Windows 11 laptop.
I was given a UDL file to use to connect to an Access mdb file.
I wrote a LabVIEW 2019 VI to create a duplicate file with the same content but a different name.
The duplicate UDL file causes the original VI to throw an error.
Supposedly the UDL file is just a text file with a different file suffix, but something is different about it.
The original UDL file has property of 404 bytes.
The duplicate UDL file has property of 199 bytes.
Since this forum does not allow .udl files, I have renamed them to .txt but the file sizes are not changed.
Solved! Go to Solution.
03-26-2022 01:01 PM
Your mistake was to assume that the UDL file was a "Text" file, that is, a file of bytes consisting of ASCII characters that spell out something like "Everything after this line is an OLE DB initstring".
Instead, the file is a binary file, consisting of a 2-byte Header (hex FF FE), and then "16-bit ASCII", with the low Byte being the ASCII characters (including CR and LF (hex 0D and 0A) and the high byte being NUL (hex 00). The proper way to read/write this file is to treat it as a Binary file, not a text file. So "Everything" in the "real" File looks like "E<nul>v<nul>e<nul>r<nul>y<nul>t<nul>h<nul>i<nul>n<nul>g<nul>".
Bob Schor
03-26-2022 01:20 PM
http://www.labview.help/topic/114998 says "
What do I know? This is new to me.
Anyway, I am not quite sure what you mean.
Open up the original as a binary file.
Write what I want to it, and LabVIEW write binary file will take care of everything?
03-26-2022 02:19 PM
@psuedonym wrote:
http://www.labview.help/topic/114998 says "
- Create a text file with a UDL extension. This is relatively easy to do in LabVIEW "
What do I know? This is new to me.
Anyway, I am not quite sure what you mean.
Open up the original as a binary file.
Write what I want to it, and LabVIEW write binary file will take care of everything?
That is not what I meant. Let me try to be clearer.
As I understand it, you are trying to read/write a UDL file, which appears to be a byte-oriented file with a particular format, including possibly text data saved in Unicode (which uses 16-bit characters, with ASCII being represented by having the high byte be 0 and the low byte be the ASCII character, just what you see). The "Text file" format that LabVIEW (and most languages) use works with 1-byte character data (ASCII, which is usually 7 bits, is called "Basic Latin" in Unicode -- adding the eighth bit gives you characters such as ½ and ° and µ).
As I said, your UDL file is a file of U16, unsigned 16-bit integers. Ignoring the first FFEE character, the rest of the file is straight ASCII, but expressed as a U16, with the top byte 0. Here's how you can go about taking Text (being sure to "include" the <CR> and <LF> that appear in the text) --
Bob Schor
03-26-2022 02:51 PM
Great.
Thanks.
NI has a couple of places mentioning that the UDL file is a simple text file. That is where I got the notion that it was text.
.
03-26-2022 02:51 PM
It is text but not ASCII text as you may assume. And it is very easy to be mistaken about this, since when you open it in Notepad (or Notepad++) it will show exactly the same information.
But it is not!
One is real ASCII (DS_temp_udl.txt) and the other is UTF16-LE text (DS_udl.txt (the Windows variant of Unicode), which is NOT ASCII! This is easily seen when you look at the binary data (Noetpad++ in Hex View or some other Hex editor). Now I can't right now open your VI so not quite sure what you are doing there, and unlike the two Notepad applications that I mentioned, most software is not prepared to transparently treat text files with the BOM (the 0xFF 0xFE bytesequence) as Unicode. LabVIEW itself does not like Unicode at all and is still a full ANSI text string application, although this is clearly not just a LabVIEW problem. The UDL file is not loaded by LabVIEW directly when you specify the UDL file path as parameter to the DB Connect VI, but that is done by the OLE DB Manager.
03-26-2022 02:59 PM
Rolf explained the "Why" much better than I (who only knew the "What").
BS
03-26-2022 03:58 PM - edited 03-26-2022 03:58 PM
@rolfk wrote:
It is text but not ASCII text as you may assume. And it is very easy to be mistaken about this, since when you open it in Notepad (or Notepad++) it will show exactly the same information.
But it is not!
One is real ASCII (DS_temp_udl.txt) and the other is UTF16-LE text (DS_udl.txt (the Windows variant of Unicode), which is NOT ASCII! This is easily seen when you look at the binary data (Noetpad++ in Hex View or some other Hex editor). Now I can't right now open your VI so not quite sure what you are doing there, and unlike the two Notepad applications that I mentioned, most software is not prepared to transparently treat text files with the BOM (the 0xFF 0xFE bytesequence) as Unicode. LabVIEW itself does not like Unicode at all and is still a full ANSI text string application, although this is clearly not just a LabVIEW problem. The UDL file is not loaded by LabVIEW directly when you specify the UDL file path as parameter to the DB Connect VI, but that is done by the OLE DB Manager.
Don't pay attention to my VI.
It is wrong.
I need to modify per Bob_Schor's post.