LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

UTF8 database bug

I doubt that it should be the Toolkits responsibility to adjust for various database interface quirks. What would work with your database interface most likely would cause errors with other ones. I'm sure the SQL server interface implements quite a different way of localization and Oracle DB again something quite different and so we can go on. Methods to determine if your database is localized or not will greatly vary between database drivers and backends so your change to the database Toolkit most likely will render it useless for other database users.

 

Such is life and there is no good solution to that for someone who tries to provide a Toolkit that should work among all possible interfaces and backends.

Rolf Kalbermatter
My Blog
0 Kudos
Message 11 of 16
(563 Views)
After looking into things a bit it seems the problem is the UTF-8 encoding. I would still assert that the issue is the database itself (or perhaps the way the toolkit is talking to it). The problemis that the UTF-8 version of postgresql expects even the sql code controlling it to be UTF-8 encoded. IMHO, this is a very bad assumption. Exacerbating this issue is that the way they implement it is to require all column names to be quoted whether they contain any unicode caracters or not. This seems to me a bad design decision. (My suspicion is that you will find that all user-entered named or labels will need to be quoted.) You are right in a sense that the toolbox should be able to hide differences between databases. The problem is that the standardization that would allow this to happen doesn't exist yet. To correctly hand,e this situation the toolkit would have to be able to query the database to determine the encoding being used, however as you saw in another posts the queries for reading the encoding settings are not standardized and can vary greatly.

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 12 of 16
(559 Views)

 


@rolfk wrote:

I doubt that it should be the Toolkits responsibility to adjust for various database interface quirks. What would work with your database interface most likely would cause errors with other ones. I'm sure the SQL server interface implements quite a different way of localization and Oracle DB again something quite different and so we can go on. Methods to determine if your database is localized or not will greatly vary between database drivers and backends so your change to the database Toolkit most likely will render it useless for other database users.

 

Such is life and there is no good solution to that for someone who tries to provide a Toolkit that should work among all possible interfaces and backends.


 

Agreed, creating good software is difficult.

 

The media player I am using can handle about 30 different media formats, audio, video, surround even compressed using the archive format "rar".

The picture viewer I am using can handle some 20 different picture formats.

And so on..

 

In soviet russia the database toolkit vendor chooses the database. Smiley Indifferent

 

Br,

 

/Roger

 

0 Kudos
Message 13 of 16
(558 Views)

 


@mikeporter wrote:
After looking into things a bit it seems the problem is the UTF-8 encoding. I would still assert that the issue is the database itself (or perhaps the way the toolkit is talking to it). The problemis that the UTF-8 version of postgresql expects even the sql code controlling it to be UTF-8 encoded. IMHO, this is a very bad assumption. Exacerbating this issue is that the way they implement it is to require all column names to be quoted whether they contain any unicode caracters or not. This seems to me a bad design decision. (My suspicion is that you will find that all user-entered named or labels will need to be quoted.) You are right in a sense that the toolbox should be able to hide differences between databases. The problem is that the standardization that would allow this to happen doesn't exist yet. To correctly hand,e this situation the toolkit would have to be able to query the database to determine the encoding being used, however as you saw in another posts the queries for reading the encoding settings are not standardized and can vary greatly.

 

Define a database toolkit "database interface" and ask for community submissions of plugin modules (eg. LV classes) for the various databases out there. Let the inerface define methods such as "vendor.vi", "version.vi", "localized.vi". If the submissions are found to be of high quality during review, then just mainline it.

 

I am sure there exist a suitable license out there that satisfies both the submitter and maintainer.

 

Br,

 

/Roger

 

0 Kudos
Message 14 of 16
(553 Views)

 


@RogerI wrote:

 

Define a database toolkit "database interface" and ask for community submissions of plugin modules (eg. LV classes) for the various databases out there. Let the inerface define methods such as "vendor.vi", "version.vi", "localized.vi". If the submissions are found to be of high quality during review, then just mainline it.

 

I am sure there exist a suitable license out there that satisfies both the submitter and maintainer.

 

 


OpenG did attempt to do such things with much more common things than database access. The result is almost always that the original author will maintain it until he or she goes to some other project and then it stays there slowly bitrotting. Community participation on such projects is very hard in all software projects and LabVIEW being in a specialistic niche makes it even more difficult since the potential user base is small in comparison and the potential developer pool even smaller.

 

And there are about at least 6 or 7 more or less generic database libraries out there for LabVIEW, most of them based on the ADO interface. None of them likely will handle Postgre specialismes, and most will limit themselves to some SQL Server and Access specialismes. Some are not actively maintained anymore. It shows another problem which is the extra fragmentation in the already small developer pool because of the "not invented here" syndrome.

 

Rolf Kalbermatter
My Blog
0 Kudos
Message 15 of 16
(534 Views)

 


@rolfk wrote:

 


@RogerI wrote:

 

Define a database toolkit "database interface" and ask for community submissions of plugin modules (eg. LV classes) for the various databases out there. Let the inerface define methods such as "vendor.vi", "version.vi", "localized.vi". If the submissions are found to be of high quality during review, then just mainline it.

 

I am sure there exist a suitable license out there that satisfies both the submitter and maintainer.

 

 


OpenG did attempt to do such things with much more common things than database access. The result is almost always that the original author will maintain it until he or she goes to some other project and then it stays there slowly bitrotting. Community participation on such projects is very hard in all software projects and LabVIEW being in a specialistic niche makes it even more difficult since the potential user base is small in comparison and the potential developer pool even smaller.

 

And there are about at least 6 or 7 more or less generic database libraries out there for LabVIEW, most of them based on the ADO interface. None of them likely will handle Postgre specialismes, and most will limit themselves to some SQL Server and Access specialismes. Some are not actively maintained anymore. It shows another problem which is the extra fragmentation in the already small developer pool because of the "not invented here" syndrome.

 


 

 

I am not advocating any replacement libraries for the various toolkits. I am all for using the vanilla LV toolkits and wrap them up in my own libs or classes. I use zero from the OpenG, GDS or VIPM libraries in my code.

 

When I talk about "the community" I am not generally referring to some loosely knit garage band of linux kernel coders. Let the database vendors provide plugins. I am sure Oracle are all for creating another interface if it can increase their sales?

 

It is all so much better than being told that the database toolkit is flawless and the problem is in the driver/backend/database. Yea, right. Smiley Wink

 

Br,

 

/Roger

 

 

0 Kudos
Message 16 of 16
(520 Views)