For some time I've got strange problem with calling oracle procedure. In vba I'm createing adodb.command object. As one of parameters I'm creating concatenated string with polish diacritic chars. Not always those chars are translated into some strange chars like ascii 15712189 instead of 50620 fot the same letter. Sometimes it's enough to restart the same sub and it works as it should.
Oracle database is 19c, Oracle client is 12. I've got 32 and 64 bit version installed.
Excel 365. It' started after I installed new disk and had to reinstall all.
I'm connecting to oracle db using odbc. In odbc definition I even set Numeric setting=Use Microsoft regional settings. In oracle definitions i registry I've got properly set NLS_LANG=POLISH_POLAND.EE8MSWIN1250
Is there a way to define what char set should be used?
Thanks for any suggestions.
Artur
Related
I have a subject table which has a theme field contains the following rows :
theme
-----
pays
économie
associée
And I have this basic query :
SELECT * FROM SUBJECT WHERE THEME='associée';
The query runs fine in Sql developer and returns the expected row to me.
On the other hand under Sqlplus it returns 0 lines to me (which is not normal).
I have the impression that the query does not recognize accented characters under sqlplus. I am thinking of an NLS_LANG problem but I do not know about it. Please help.
Thank you in advance.
Set your OS session's NLS_LANG variable to the value of, e.g., ENGLISH_AMERICA.AL32UTF8 and restart your SQL Developer. Retry afterwards.
If that didn't help, try also running your query as follows:
SELECT * FROM SUBJECT WHERE THEME = n'associée';
Notice the n before the string literal. That's a nvarchar2 string literal modifier. Depending on your DB charset/national charset settings you may need to explicitly state that the value you are querying for, is "national charset", not just a "regular charset".
If that didn't help, there's actually a multitude of additional variables that come into play when working with accented characters against an Oracle DB.
Explanation:
Your SQL Developer does recognize accents... provided that you have your Oracle DB session using character set compatible with your database character set. And your Oracle DB session's character set can be set either on OS level (via OS environment variable) or, possibly(!), in SQL Developer's options directly. Alas, the said multitude of other factors may include (though not exclusively):
your OS regional settings,
your OS Unicode support,
your Oracle client software's (SQL Developer) Unicode support,
your Java JDK/JRE's Unicode support,
your JDBC driver's Unicode support,
your other *DBC drivers' Unicode support, if there are any more in chain.
Sad thing is that the more interfaces you have between your keyboard and your Oracle database, the more likely is one of them to fiddle with your charset conversions badly.
So, let's just hope that the first two hints work for you, otherwise I can't help you (that easily).
I have a problem when inserting values into my Oracle database. I have to insert French characters like à or è and when I try to insert them through an INSERT statement it will convert the character to ¿ or ?.
Is there any possibility to set the encoding of that specific script, or what can I do in this situation ?
Thank you
Usually you would set the character set when you install your database. You can, however, change it post-setup if required (Look up CSALTER). If your database needs to support multiple languages, then you should take a look at this: Supporting Multilingual Databases with Unicode
I have fixed this problem by adding an Environment Variable called NLS_LANG with the value .AL32UTF8 . This worked even though the database has as language American and territory America. The problem that I have faced here was that once I changed the NLS_LANG variable, it started to encode my characters also in the application.
Also you can try to change the encoding of the script that you are running. For example I have used ANSI encoding (you can do it by opening a script in notepad++ and from the Encoding menu, select Convert to ANSI) and it worked properly.
Thank you guys for your help :)
I'm attempting to run a simple statement against an Access DB to find records.
Data validation in the records was horrible, and I cannot sanitize it. Meaning, it must be preserved as is.
I need to be able to search against a string with white space and hyphen characters removed. The following statement will work in Access 2010 direct:
select * from dummy where Replace(Replace([data1],' ',''),'-','') = 'ABCD1234';
Running it from an ODBC connection via PHP will not. It produces the following error:
SQL error: [Microsoft][ODBC Microsoft Access Driver] Undefined function 'Replace' in expression., SQL state 37000 in SQLExecDirect
Creating a query in the database that runs the function and attempting to search its values indirectly causes the same error:
select * from dummy_indirect where Expr1 = 'ABCD1234';
I've attempted to use both ODBC drivers present. ODBCJR32.dll (03/22/2010) and ACEODBC.dll (02/18/2007). To my knowledge these should be current as it was installed with the full Access 2010 and Access 2010 Database Engine.
Any ideas on how to work around this error and achieve the same effect are welcome. Please note, that I cannot alter the database in way, shape, or form. That indirect query was created in another mdb file that has the original tables linked from the original DB.
* Update *
OleDB did not really affect anything.
$dsn= "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\dummy.mdb;";
I'm not attempting to use it as a web backend either. I'm not a sadomasochist.
There is a legacy system that I must support that does use Access as a backend. Data gets populated there from other old systems that I must integrate into more modern systems. Hence, the creation of an API with Apache/PHP that is running on the server supporting the legacy system.
I need to be able to search a table that has an alphanumeric case identifier to get a numeric identifier that is unique and tied to a generator (Autonumber in access). Users have been using it a trash box for years (inconsistent data entry with sporadic notations) so the only solution I have is to strip everything except alphanumeric out of both the field value and the search value and attempt to perform a LIKE comparison against it.
If not replace() which is access supported, what ODBC compatible functions exist that I can use do the same kind of comparison?
Just to recap, the Access db engine will not recognize the Replace() function unless your query is run from within an Access application session. Any attempt from outside Access will trigger that "Undefined function" error message. You can't avoid the error by switching from ODBC to OleDb as the connection method. And you also can't trick the engine into using Replace() by hiding it in separate query (in the same or another Access db) and using that query as the data source for your main query.
This behavior is determined by Access' sandbox mode. That linked page includes a list of functions which are available in the default sandbox mode. That page also describes how you can alter the sandbox mode. If you absolutely must have Replace() available for your query, perhaps the lowest setting (0) would allow it. However, I'm not recommending you do that. I've never done it myself, so don't know anything about the consequences.
As for alternatives for Replace(), it would help to know about the variability in the values you're searching. If the space or dash characters appear in only one or a few consistent positions, you could do a pattern match with a Like expression. For example, if the search field values consist of 4 letters, an optional space or dash, followed by 4 digits, a WHERE clause like this should work for the variations of "ABCD1234":
SELECT * FROM dummy
WHERE
data1 = 'ABCD1234'
OR data1 Like 'ABCD[- ]1234';
Another possibility is to compare against a list of values:
SELECT * FROM dummy
WHERE
data1 IN ('ABCD1234','ABCD 1234','ABCD-1234');
However if your search field values can include any number of spaces or dashes at any position within the string, that approach is no good. And I would look real hard for some way to make the query task easier:
You can't clean the stored values because you're prohibited from altering the original Access db in any way. Perhaps you could create a new Access db, import the data, and clean that instead.
Set up the original Access db as a linked server in SQL Server and build your query to take advantage of SQL Server features.
Surrender. :-( Pull in a larger data set to your PHP client code, and evaluate which rows to use vs. which to ignore.
I'm not sure you can do this with ODBC and your constraints. The MS Access driver is limited (by design; MS wants you to use SQL Server for back ends).
Can you use OLEDB? that might be an option.
I can see the Japanese test in the excel cells. I've built the insert query using ADO. It does the insert in the DB, but Japanese characters are simply represented as "????"
Any help would be appreciated.
Is it the Sybase client where you are seeing the Japanse characters misrepresented? If you are lucky then it's just a mix-up between the server and a client. You can try running:
set char_convert off
in the Sybase client which will turn off Sybases automatic character conversion that it attempts to do.
If the above doesn't work then you have to find out what your Sybase servers default charset is. You can do this with:
sp_default_charset
This will return the default charset for your Sybase server (e.g roman8 ). Check the charset your server returns supports Japanese characters.
I'm working on a legacy product and i have some SQL being executed through ADO, to an Access database with linked tables to SQL Server. I'm getting the error 'Undefined function 'Round' when i execute the SQL but if i take the query and run directly in Access it works fine. I know that EVERYTHING is correct and that this is a machine specific issue since this is production code, it works on other machines and has been deployed successfully for many clients.
I'm not even sure where to begin to be honest. I'm running the correct (latest) versions of Jet/ADO/MDAC.
ANY help would be appreciated.
Thanks in advance.
EDIT: Obviously, the SQL includes the aggregate function 'Round'. I'm aware of the differences between Jet and SQL implementations. This problem is due to some problem with a component on my machine and NOT with the code. The SQL executes properly when done through MS Access 2007 but NOT through ADO.
EDIT2: Right solution from the comments:
shahkalpesh: If it executes fine thru Access, it could be that Access has the DLL available to it, which has the Round function. What is the connection string, you are using?
Stimul8d: I'm not sure how it can be anything so do with the connection string. This code works on EVERY other machine, with no changes; just not on mine.
Andomar: Well, that's your problem right there, your machine is farked up. You can still install vb6 sp6 maybe.
Stimul8d: Well, SP6 fixed it. Cheers Anndomar, no idea why SP6 fixed it but it did!
EDIT: Based on your comment this newsgroup post might be the answer:
Unfortunately, when you are running
queries from outside of Access (as you
are from VB), your only connection to
the database is through the Jet
engine, which doesn't know anything
about most VBA functions. There's no
way around this, other than to return
the data to your VB application and
use the functions on the data there.
And two posts later:
I solved the problem. Updated my VB
with the Service Pack 6... it took
care of the problems.
Old answer here:
Try FLOOR() instead of ROUND().
To round something to the nearest integer, you could:
declare #floatmyboat float
set #floatmyboat = 1.51
select floor(#floatmyboat+0.5)
P.S. Maybe post the exact error you get. If it's "The round function requires 2 to 3 arguments.", that means Sql Server is borking on the ROUND().
The round() function exists in SQL Server as well.
The only difference is: in Access the precision is an optional parameter, but in SQL Server you have to specify it.
So this will only work in Access, but not in SQL Server:
select round(Column) from Table
This will work in Access and SQL Server:
select round(Column,1) from Table
it could be that Access has the DLL
available to it, which has the Round
function
ACE/Jet uses share expression services with VBA. Broadly speaking, ACE/Jet supports as expressions all VBA5 functions (as distinct from methods) whose arguments and return values are scalar types (e.g. no arrays, no objects). The Round() expression falls into this definition and indeed is available to ACE/Jet with the same semantics as its VBA function equivalent. As anyone familiar with the ACE/Jet engine should know, though, the semantics can differ from the VBA equivalents e.g. ACE/Jet ANSI-92 Query Mode SQL
SELECT TYPENAME(ROUND(5, 1))
returns 'Long', whereas VBA
?Typename(Round(5, 1))
returns 'Integer'.
In other words, Round() wasn't going to be the problem here.