- 3,715,714 Users
- 2,242,841 Discussions
- 7,845,505 Comments
Forum Stats
Discussions
Categories
- 17 Data
- 362.2K Big Data Appliance
- 7 Data Science
- 1.6K Databases
- 467 General Database Discussions
- 3.7K Java and JavaScript in the Database
- 22 Multilingual Engine
- 487 MySQL Community Space
- 3 NoSQL Database
- 7.6K Oracle Database Express Edition (XE)
- 2.8K ORDS, SODA & JSON in the Database
- 416 SQLcl
- 42 SQL Developer Data Modeler
- 184.9K SQL & PL/SQL
- 21K SQL Developer
- 1.9K Development
- 3 Developer Projects
- 32 Programming Languages
- 135.1K Development Tools
- 9 DevOps
- 3K QA/Testing
- 248 Java
- 5 Java Learning Subscription
- 10 Database Connectivity
- 66 Java Community Process
- 1 Java 25
- 9 Java APIs
- 141.1K Java Development Tools
- 6 Java EE (Java Enterprise Edition)
- 153K Java Essentials
- 135 Java 8 Questions
- 86.2K Java Programming
- 270 Java Lambda MOOC
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 10 Java SE
- 13.8K Java Security
- 3 Java User Groups
- 22 JavaScript - Nashorn
- 18 Programs
- 125 LiveLabs
- 30 Workshops
- 9 Software
- 3 Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 3 Deutsche Oracle Community
- 10 Español
- 1.9K Japanese
- 2 Portuguese
Missing non-ASCII character support

It looks like there are issues with non-ASCII characters in the MLE. Here's an example. You may run it in the SQL workshop.
CREATE JAVASCRIPT SOURCE NAMED "greeting.js" ASmodule.exports.greeting = function (person) { return "Hello " + person + "!";}/CREATE OR REPLACE FUNCTION greeting(in_person IN VARCHAR2) RETURN VARCHAR2 AS LANGUAGE JS NAME 'greeting.js.greeting(person string) return string';/SELECT greeting('John McEnroe'), greeting('Björn Borg') FROM dual;
The result is:
Best Answer
-
Hi Philipp,
thank you very much for trying out our APEX demo and for your report. Deploying JavaScript and Python functions via the DDL and calling them from SQL / PL/SQL is not an official feature of the APEX demo. This is still work in progress and not complete yet. For example, we currently only support 7-bit ASCII characters for calls from SQL. However, Unicode should work without problems in Dynamic MLE that has been integrated with APEX.
Best regards,
Bastian
Answers
-
Hi Philipp,
thank you very much for trying out our APEX demo and for your report. Deploying JavaScript and Python functions via the DDL and calling them from SQL / PL/SQL is not an official feature of the APEX demo. This is still work in progress and not complete yet. For example, we currently only support 7-bit ASCII characters for calls from SQL. However, Unicode should work without problems in Dynamic MLE that has been integrated with APEX.
Best regards,
Bastian
-
Hello Bastian,
Thank you for the prompt answer and the clarification.
Yes, unicode works as expected when used in an APEX process. However, the page 3 "Simple Input Form" of the MLE Sample App uses "validator.js" to validate a given e-mail address. The validation fails, when for example a German umlaut is used within the e-mail address. Umlauts in e-mail addresses are valid. See also https://npm.runkit.com/validator. And this part of the APEX demo seems to be affected of the 7-bit ASCII limitation. ;-)
Regards,
Philipp
-
Hi Philipp,
you are absolutely correct. The e-mail validation example on page 3 of the APEX-MLE demo does indeed not work with non-ASCII characters. The tab "About validator.js" explains how validator.js has been deployed as a MLE module for the demo. All calls to it go through the SQL layer behind the scenes. As you guessed, this then introduces the limitation to 7-bit ASCII characters. The limitation will go away as soon as we fully support Unicode for calls from SQL.
Best regards,
Bastian