I'm playing around with the Azure Date Explorer service. Am trying to follow the tutorial and create a table using:
.create table StormEvents (StartTime: datetime, EndTime: datetime, EpisodeId: int, EventId: int, State: string, EventType: string, InjuriesDirect: int, InjuriesIndirect: int, DeathsDirect: int, DeathsIndirect: int, DamageProperty: int, DamageCrops: int, Source: string, BeginLocation: string, EndLocation: string, BeginLat: real, BeginLon: real, EndLat: real, EndLon: real, EpisodeNarrative: string, EventNarrative: string, StormSummary: dynamic)
However I get the message:
Error Entity name 'N/A' of kind 'Database' does not exist. clientRequestId: KustoWebV2;38b1da41-5827-4d55-986a-457190528f82
The .create table command must run in the context of a specific database.
If you haven't yet created a database, you'll need to create one first, in order to create a table.
Make sure you're "pointing" to a database you have the required permissions (DatabaseUser or higher) to in the connections panel on the left site of the UX, and that you're not "pointing" to the Azure Data Explorer cluster itself.
Ok I worked it out. There appears to be a bug.
After you create a database using the Azure portal, and you click query. You will see it says error in that middle pane where the cluster is shown.
Go back to your cluster overview, grab the URL (i.e. https://DBNAME.YOURREGION.kusto.windows.net)
Go to where the error is show, click edit, then paste in the URI
It should now work. Also interestingly when you hit edit again the URL is displayed as the same short-form that you had when you had the error nut somehow pasting it in again has fixed it.
If you are creating a table via the portal in the "Query" section, you need to make sure your scope is on the database, not on the cluster itself. Click on the >> button and you will see the cluster, hit refresh and click on the database underneath to select the database scope. Now execute the query again and it will work.
Related
trying to create a trigger in Xcode / Swift5 / GRDB. the trigger in the codeblock below fails silently, so I move it and see the error in the title [I have removed the text of the SQL statement from the title]. the weird part is that DB Browser will run the SQL and CREATE the trigger just fine. and the app responds as expected with the externally created trigger. and the UPDATE within seems to work fine outside of the trigger.
opened an issue with the GRDB github repo...just passing the raw SQL thru. check several validators online. all either said there was nothing wrong, or failed on CREATE TABLE in the block below...so no faith in any of the validators.
remembered I have DraftCode on the ipad, with phpLiteAdmin included. send the SQL over and get the same incomplete input error. move back to the desktop...update PHP, and get phpLiteAdmin...same error.
so...it's either a SQLite bug like https://github.com/sqlitebrowser/sqlitebrowser/issues/1470? or more likely a syntax error on my part. I've never played with triggers before...so I may be the dumbass overlooking the obvious. if so, please help me rectify.
one more bit of interesting... in phpLiteAdmin, using the trigger builder, everything works just fine. but trying to run the resulting create SQL statement, copied/delete trigger/and pasted back in, generates the same error
SQLite version: 3.31.1
PHP version: 7.3.14
phpLiteAdmin version: 1.9.8.2
any help with creating the trigger in either GRDB or phpLiteAdmin as a SQL statement would be appreciated. thnx.
CREATE TABLE CartItem (
id INTEGER PRIMARY KEY AUTOINCREMENT,
transactionID INTEGER DEFAULT NULL,
wasReceived BOOLEAN,
sku VARCHAR,
label VARCHAR,
description VARCHAR,
unitLabel VARCHAR,
cost DOUBLE,
wholesale DOUBLE,
retail DOUBLE,
tax DOUBLE,
cartQty FLOAT,
modified REAL
);
-- because 'transaction' is reserved
CREATE TABLE TransXion (
id INTEGER PRIMARY KEY AUTOINCREMENT,
transactionNum VARCHAR,
shippingSubtotal DOUBLE,
taxableSubtotal DOUBLE,
nontaxableSubtotal DOUBLE,
subtotal DOUBLE,
total DOUBLE,
paymentsSubtotal DOUBLE,
balance DOUBLE,
itemsWereRcvd BOOLEAN,
locked BOOLEAN,
modified REAL
);
CREATE TRIGGER insert_TransXion_Dollar_Values_trigger
AFTER INSERT ON CartItem
WHEN transactionID = new.transactionID
BEGIN
UPDATE TransXion
SET total = (
SELECT SUM(ci.retail) AS retail_total
FROM CartItem ci
WHERE ci.transactionID = TransXion.id
)
WHERE id IN (
SELECT transactionID
FROM CartItem ci
WHERE ci.transactionID = TransXion.id
);
END;
In phpLiteAdmin's SQL tab, statements are separated by the delimiter that you can configure below the input tab. By default, this is ;.
In your trigger definition you use ;, but splitting what you enter at this point results in those two queries:
First query:
CREATE TRIGGER insert_TransXion_Dollar_Values_trigger
AFTER INSERT ON CartItem
WHEN transactionID = new.transactionID
BEGIN
UPDATE TransXion
SET total = (
SELECT SUM(ci.retail) AS retail_total
FROM CartItem ci
WHERE ci.transactionID = TransXion.id
)
WHERE id IN (
SELECT transactionID
FROM CartItem ci
WHERE ci.transactionID = TransXion.id
);
second query:
END;
So this obviously fails. You can simply configure another delimiter like $ to make sure it executes as one query.
Objective: Using MariaDB I want to read some data from MS SQL Server (via ODBC Connect engine) and SELECT INSERT it into a local table.
Issue: I keep geting "error code 1406 data too long" even if source and destination varchar fields have the very same size (see further details)
Details:
The query which I'm trying to execute is in the form:
INSERT INTO DEST_TABLE(NUMERO_DOCUMENTO)
SELECT SUBSTR(TRIM(NUMERO_DOCUMENTO),0,5)
FROM CONNECT_SRC_TABLE
The above is the very minimal subset of fields which causes the problem.
The source CONNECT Table is actually a view inside SQL Server. The destination table has been defined so to be identical to the the ODBC CONNECT Table (same field names, same NULL constranints, same filed types ans sizes)
There's no issue on a couple of other VARCHAR fields
The issue is happening with a filed NUMERO_DOCUMENTO VARCHAR(14) DEFAULT NULL where the max length from the input table is 14
The same issue is also happening with 2 other fields ont the same table
All in all it seems to be an issue with the source data rather then the destination table.
Attemped workarounds:
I tried to force silent truncation but, reasonably, this does not make any difference: Error Code: 1406. Data too long for column - MySQL
I tried enlarging the destination field with no appreciable effect NUMERO_DOCUMENTO VARCHAR(100) DEFAULT NULL
I tried to TRIM the source field (hidden spaces?) and to limit its size at source to no avail: INSERT INTO DEST_TABLE(NUMERO_DOCUMENTO) SELECT SUBSTR(TRIM(NUMERO_DOCUMENTO),0,5) FROM CONNECT_SRC_TABLE but the very same error is always returned
Workaround:
I tried performing the same thing using a FOR x IN (src_query) DO INSERT .... END FOR and this solution seems to work: this means that the problem is not into the data itself but in how the engine performs the INSERT SELECT query
I've created this package with a PL/SQL type inside in Oracle 11.2.0.3 database:
CREATE OR REPLACE PACKAGE "DBATCK"."PKG_TCK_MGMTCK" AS
...
TYPE TYPE_SHOW_USR
is table of DBATCK.VW_SHOW_USR%ROWTYPE;
...
END PKG_TCK_MGMTCK;
/
Oracle automatically creates a type named
create or replace type SYS_PLSQL_342468_34_1 as object
(
"IDCODEAMB" NUMBER,
"DESCRAMB" VARCHAR2(50 BYTE),
"IDCODEAPP" VARCHAR2(7 BYTE),
"DESCRAPP" VARCHAR2(50 BYTE)
);
but if I change the column DESCRAPP from varchar2(50) to varchar2(100) in the table SHOW_USR and in the view VW_TCK_USERS, when I recompile the package PKG_TCK_MGMTCK the PL/SQL type doesn't change.
Why?
--TABLE
create table DBATCK.SHOW_USR
(
"IDCODEAMB" NUMBER,
"DESCRAMB" VARCHAR2(50 BYTE),
"IDCODEAPP" VARCHAR2(7 BYTE),
"DESCRAPP" VARCHAR2(50 BYTE)
);
--VIEW
create view DBATCK.VW_SHOW_USR as select * from DBATCK.SHOW_USR;
This seems to be a bug when defining the collection type against a view rather than a table. Altering the table definition invalidates the view and package specification/body as expected, but not the types1; so when the view and package are implicitly recompiled on next reference the types seem to be overlooked.
Recompiling the package or view, or even explicitly reissuing the create or replace command for the package specification and body, doesn't seem to have any effect.
Even completely dropping the package before recreating it doesn't help, as the type is linked to the view rather than the package (the related object's ID is part of the type name).
You could drop the view and then recreate that, and the next package reference would then recreate the type too; but then you would have to reinstate privileges on it (and of course it won't exist briefly, so if you try to do that outside a maintenance window other things might fail as a result).
You don't have to be quite that brutal though. Although recompiling the view doesn't help, redefining it in-place does:
create or replace view VW_SHOW_USERS as select * from SHOW_USR;
which ought to be less disruptive than dropping it, as privileges against the view will be retained.
I've created a db<>fiddle demo showing the initial problem and various unsuccessful attempts to correct it, followed by view redefinition.
1 If the collection is defined directly against the table instead of against the view then the type is invalidated by the alter table too, so it does get recompiled with the new definition, and this problem doesn't appear. When using the view it looks like something is being missed when the dependencies are evaluated. It may be worth raising a service request with Oracle to get this investigated. (I've only been able to very this behaviour up to 12cR2; perhaps someone can verify what happens in 18?)
I have a DB in a Rails app I'm developing that had a product_type field defined as varchar(255) (in SQLite Manager) that ended up being a foreign key. I changed the name to product_type_id and the type to integer using a migration in Rails to use the existing id field in the other product_type file. When it was complete, SQLite Manager in Firefox shows the type as integer(255) rather than just integer.
What is an integer(255)? An answer to another question here said the (255) was a display width. Is that correct? There is no data in the database at present. Should I delete and recreate the field to get an integer, otherwise the data types on the two fields won't match.
The integer(255) came about because a string field [ varchar(255) ] was converted to an integer and the DB maintained the field size so it might possibly hold the old data when converted during the change. Apparently, most DBs don't support integers that large. Some will ignore the size specification but others will error. Regardless, the result was not what I'd intended.
I found that the way to remove the limit was to perform a migration in Rails and set the limit to nil.
class RemoveIntegerLimits < ActiveRecord::Migration
def up
change_column :inv_x_refs, :company_id, :integer, limit: nil
end
end
i'm using the SQLite function from phonegap(1.2) on my app, and after quitting the application and restarting it, all data that i previously stored to the database is gone. how can i prevent loosing the data and where is the application stored on the device(Android, iPhone).
Create Table:
function favouritesInit(transaction){
transaction.executeSql('CREATE TABLE IF NOT EXISTS FAVOURITES (id INTEGER PRIMARY KEY, lat, ln, title, cont)');
}
Insert:
var statement = 'INSERT INTO FAVOURITES (lat, ln, title, cont) values('+the_fav.getPosition().lat()+', '+the_fav.getPosition().lng()+', '+the_fav.getTitle()+', '+content+')';
transaction.executeSql(statement);
thanks
You should make sure the problem is that the database is dropped once you close your application. It seems to me that it is just that the data is not getting into the database with your insert. With that code you passed, I can only guess, but if I were you I would run a transaction to read the data from the database right after inserting it just to make sure it actually makes its way to the database.
The problem is that your not passing a value for the primary key.
Your table has an id as primary key, and because of that it can't be null. The only exception is when you declare the id as 'AUTOINCREMENT': in that case, if you don't pass a primary key value, the database will assign the next available value from a sequence table created for that purpose.
Hope this helps: https://www.sqlite.org/autoinc.html
Cheers!