In my AzerothCore whenever I try to login, it's stuck at Retrieving character list.
The solution to this issue is truncating the table instance_reset of the characters database (acore_characters).
Related
We are facing issue in reading non-english (chineese) character using executeSql from oracle clob field. The character are getting converted to junk value. The executeSql works fine on varchar fields having such character but having issue with CLOB, NCLOB.
Have anyone faced this situation before and can you suggest a possible fix.
This is my first time to use SQLPlus and Oracle. (exploring other DBMS) :)
Using SQL Plus, I'm trying to create user.
SQL> create user <username> identified by <password>;
But it shows error:
ORA-00922: missing or invalid option
What do I missed?
:(
According to the oracle DOCS:
Nonquoted identifiers must begin with an alphabetic character from your database character set. Quoted identifiers can begin with any character.
so its good practice to use quotes around the password!
ref: https://docs.oracle.com/cd/B19306_01/server.102/b14200/sql_elements008.htm
Using Oracle 11gR2
You can't create a username starting with a number:
SQL> create user 123 identified by temp;
create user 123 identified by temp
*
ERROR at line 1:
ORA-01935: missing user or role name
However, you can create it as:
SQL> create user "123" identified by temp;
User created.
Somebody knows possible problems with this kind of users?
Somebody knows oracle rules/reasons why you can't create it without quotes, ie, to have usernames starting with numbers?
Thanks in advance
Problems with quoted identifiers
Quoted identifiers can be successfully used for almost any Oracle object, including users. In theory, they work everywhere. In practice, you will run into many inconveniences and problems with quoted identifiers.
From the SQL Language Reference:
"Note: Oracle does not recommend using quoted identifiers for database object names. These quoted identifiers are accepted by SQL*Plus, but they may not be valid when using other tools that manage database objects."
Once you use double quotes, every reference to that object must use double quotes, and the correct case. You'll find lots of problems with tools that don't always use double quotes. And problems with scripts that look at metadata and don't always add double quotes. Quoted identifiers are just asking for trouble.
Why does Oracle have quoted identifiers?
This question is harder to answer, but I would guess limiting the types of characters used by objects makes parsing much easier. SQL already has a lot of keywords, and has many weird language ambiguities. If object names started with numbers it would make it difficult to differentiate between real numbers and objects.
For example, without quoted identifiers, this simple statement could be a mess:
select 1.1 + 2.2 from some_table;
Without restricting object names, 1.1 could be a huge number of things, and the parser would have to look for objects named "1", and then dependent objects named "1", and then determine if that takes precedence over the number "1.1".
Weird names are possible in languages, but I assume when someone wrote the first SQL compiler 40 years ago they decided not to make their lives so complicated just to accommodate a few weird names.
Check if the user name is not present in reserved words and doesn't start with number:
SELECT *
FROM v$reserved_words
ORDER BY keyword
If you are creating user try this:
alter session set "_ORACLE_SCRIPT"=true;
CREATE USER oe IDENTIFIED BY oe;
check your connection type is cdb or not. if it is cdb as shown in the below
image
use prefix c## before the username in the command for creating user
I'm using the following command to update a field in my database:
UPDATE Movies SET 'From'=2 WHERE 'Name'="foo";
I'm using sqlite3.exe in windows (command prompt). Although no error message is produced, nothing changes in the table. I examined the database with a couple of gui tools and I'm sure UPDATE does nothing.
'From' is of type integer and 'Name' is text.
The problem you've got is that you're getting your quoting wrong. SQLite follows the SQL standard here, and that specifies what quote characters to use: '…' is for strings, and "…" is for tokens (like special names used as column or table names). Sometimes it manages to guess what you mean anyway and compensate for getting it wrong, but it can't with the WHERE clause because that is syntactically correct (if decidedly unhelpful):
Swapping the quoting appears to work:
UPDATE Movies SET "From"=2 WHERE "Name"='foo';
Those aren't good column names. Both are keywords, best avoided, and not self-explanatory at all.
Do a SELECT to see how many rows match the WHERE clause in the UPDATE. If none come back, you have your answer.
Did you commit the UPDATE? Is auto commit turned on?
I am using Xojo 2013 Version 1. I am trying to delete a record from a SQLite database. But I am failing miserably. Instead of deleting the record, it duplicates it for some reason.
Here is the code that I use:
command = "DELETE * from names where ID = 10"
namesDB.SQLExecute(command)
I am dynamically generating command. but however I change it it always does the same. Same result with or without quotes.
Any ideas?
The very first thing I would do is check to see if there is an error being generated.
if namesDB.Error then
dim s as string = namesDB.errorMessage
msgbox s
return
end
It will tell you if there's a database error and what the error is. If there's no error then the problem lies elsewhere.
FWIW, always, always, always check the error bit after every db operation. Unlike other languages, Xojo does NOT generate/throw an exception if there's a database error so it's up to you to check it.
Try calling Commit().
I just made a sample SQLite database with a "names" table, and this code worked fine:
db.SQLExecute("Delete from names where ID=2")
db.Commit
I have done a lot of work with XOJO and SQLite, and they work well together. I have never seen a record duplicated erroneously as you report. That is very weird. If this doesn't help, post more of your code. For example, I assume your "command" variable is a String, but maybe it's a Variant, etc.
I think on SQLite you don't need the * between the DELETE and the FROM.