I have variables in a column named Tier. Please see below some examples;
Tier
Tier 1 (Unspecified)
Tier 7 (Anti-client)
Tier 3 (Priority)
I would like the variables to be transformed like the below;
Tier
Tier 1
Tier 7
Tier 3
Would you know how to efficiently remove all the strings in brackets at the end of the variables?
Thanks
Chris
Is this what you need?
create table #table1
(id int
,Tier varchar(100)
)
insert into #table1 VALUES
(1, 'Tier 1 (Unspecified)'),
(2, 'Tier 7 (Anti-client)'),
(3, 'Tier 3 (Priority)')
select id,
substring(tier, 1, charindex('(', tier) - 1) as Tier
from #table1
You can use substring(tier, 1, charindex('(', tier) - 2) as Tier if you are sure that there's a space before the bracket
Related
Insert into Tamil_language values (1, N'மோதிரம்')
Insert into Tamil_language values (2, 'மோதிரம்')
Select * from Tamil_language
Output
i j
----------- ----------
1 மோதிரம்
2 ???????
How to do this using store procedure in Oracle Database?
How To Add 'N' Prefix For the Store procedure Parameter?
Please Help me if any one know this.
I have a table that is being generated via INSERT INTO from a view. The data looks like this:
Priority ID Status
1 108999_1_S010 Planned
1 108999_1_S020 Planned
1 108996_1_S030 Planned
1 108996_1_S035 Planned
1 108996_1_S040 Planned
1 108996_1_S050 Planned
1 108996_1_S060 Planned
1 108996_1_S070 Planned
1 108996_1_S080 Planned
1 108996_1_S090 Planned
1 108996_1_S100 Planned
1 108996_1_S110 Planned
1 108996_1_S120 Planned
2 108999_2_S010 Planned
2 108999_2_S020 Planned
2 108996_2_S030 Planned
2 108996_2_S035 Planned
2 108996_2_S040 Planned
2 108996_2_S050 Planned
2 108996_2_S060 Planned
2 108996_2_S070 Planned
2 108996_2_S080 Planned
2 108996_2_S090 Planned
2 108996_2_S100 Planned
2 108996_2_S110 Planned
2 108996_2_S120 Planned
3 108999_3_S010 Planned
3 108999_3_S020 Planned
3 108996_3_S030 Planned
3 108996_3_S035 Planned
3 108996_3_S040 Planned
3 108996_3_S050 Planned
3 108996_3_S060 Planned
3 108996_3_S070 Planned
3 108996_3_S080 Planned
3 108996_3_S090 Planned
3 108996_3_S100 Planned
3 108996_3_S110 Planned
3 108996_3_S120 Planned
4 108999_4_S010 Planned
4 108999_4_S020 Planned
4 108996_4_S030 Planned
4 108996_4_S035 Planned
4 108996_4_S040 Planned
4 108996_4_S050 Planned
4 108996_4_S060 Planned
4 108996_4_S070 Planned
4 108996_4_S080 Planned
4 108996_4_S090 Planned
4 108996_4_S100 Planned
4 108996_4_S110 Planned
4 108996_4_S120 Planned
5 110225_1_S010 Planned
5 110225_1_S020 Planned
5 110224_1_S030 Planned
5 110224_1_S035 Planned
5 110224_1_S040 Planned
5 110224_1_S050 Planned
5 110224_1_S060 Planned
5 110224_1_S070 Planned
5 110224_1_S080 Planned
5 110224_1_S090 Planned
5 110224_1_S100 Planned
5 110224_1_S110 Planned
5 110224_1_S120 Planned
The Priority is being generated upon insertion using the ROW_NUMBER() function on the view. As you can see from the ID column, there are 14 sub-stations for any given order so there will be fourteen equivalent numbers for each priority. This is all well and good, but this table is being continuously updated via PowerApps and Power Automate. There are two requirements that I have for this table:
If a new set of orders come in from the underlying source view and their priority is, for example 3, then I would need the current orders with priority (3, 4, 5) to all shift one to (4, 5, 6).
If the status column of a particular ID changes from "Planned" to "Completed", then that row's Priority becomes 0 and the next Priority order for that station shifts to that position. (For example, if the order with ID "108996_2_S030" (which has priority 2) is finished, then the priority of this order becomes 0 and order "108996_3_S030" becomes 2. And the subsequent orders all become Priority - 1.
I'm thinking I need two separate stored procedures for this. Triggered by insertion from the view and upon change of the the status column. However, I am not sure how to write them so they don't interfere with each other.
Originally, I was going to just recalculate the priority entirely every time one of these triggers, but the caveat is that we also need to be able to manually change the priority via PowerAppss so I don't want to reset those changes.
Does anybody have any clue on how I could write stored procedures that will achieve the result for me?
So here's what I have so far:
SELECT
ROW_NUMBER() OVER (PARTITION BY [Workstation] ORDER BY [Ship Date], [RootID], [Workstation]) as Priority
,bm.[Customer]
,[ProductionOrder]
,[RootID]
,[SalesOrder]
,[Line]
,[QtyID]
,[TotalQty]
,[Material]
,[Config]
,[Description]
,[Workstation]
,[ConfigGroup]
,[Business Unit]
,[StartDate]
,[FinishDate]
,[ShipDate]
INTO #OrderInsert
FROM
[BoomsBuildMaster] as bm
INNER JOIN
[BoomsBuildScheduleTEST] as bs
ON bm.RootID = bs.[Sales Order] + '_' + bs.[Line No]
WHERE bm.ProductionOrder NOT IN (SELECT [ProductionOrder] FROM [BoomsBuilder])
AND bs.Status = 'Ready'
UPDATE [BoomsBuilder]
SET Priority = Priority + (SELECT (MAX(Priority) - MIN(Priority) + 1) FROM #OrderInsert)
WHERE Priority >= (SELECT MIN(Priority) FROM #OrderInsert)
INSERT INTO [BoomsBuilder]
(
[Priority]
,[Customer]
,[ProductionOrder]
,[RootID]
,[SalesOrder]
,[Line]
,[QtyID]
,[TotalQty]
,[Material]
,[Config]
,[Description]
,[Workstation]
,[ConfigGroup]
,[Business Unit]
,[StartDate]
,[FinishDate]
,[ShipDate]
)
SELECT * FROM #OrderInsert;
What's happening here: this stored procedure will fire when table [BoomsBuildScheduleTEST] gets a row updated to Status "ready".
So let's say three new orders are entered in at the same time with priorities (5, 6, 7). Then the current (5, 6, 7) orders would be pushed to (8, 9, 10) and anything after that will be pushed out to (11, 12, 13...). And then the new (5, 6, 7) would be inserted.
This will work for a single order being inserted, or even multiple orders that are sequential in priority. HOWEVER, it will not work if, for example, two new orders are added in and the priorities are (3,7) respectively. Not sure what to do in that case.
Let's say that we have to store information of different types of product in a database. However, these products have different specifications. For example:
Phone: cpu, ram, storage...
TV: size, resolution...
We want to store each specification in a column of a table, and all the products (whatever the type) must have a different ID.
To comply with that, now I have one general table named Products (with an auto increment ID) and one subordinate table for each type of product (ProductsPhones, ProductsTV...) with the specifications and linked with the principal with a Foreign Key.
I find this solution inefficient since the table Products has only one column (the auto incremented ID).
I would like to know if there is a better approach to solve this problem using relational databases.
The short answer is no. The relational model is a first-order logical model, meaning predicates can vary over entities but not over other predicates. That means dependent types and EAV models aren't supported.
EAV models are possible in SQL databases, but they don't qualify as relational since the domain of the value field in an EAV row depends on the value of the attribute field (and sometimes on the value of the entity field as well). Practically, EAV models tend to be inefficient to query and maintain.
PostgreSQL supports shared sequences which allows you to ensure unique auto-incremented IDs without a common supertype table. However, the supertype table may still be a good idea for FK constraints.
You may find some use for your Products table later to hold common attributes like Type, Serial number, Cost, Warranty duration, Number in stock, Warehouse, Supplier, etc...
Having Products table is fine. You can put there all the columns common across all types like product name, description, cost, price just to name some. So it's not just auto increment ID. Having an internal ID of type int or long int as the primary key is recommended. You may also add another field "code" or whatever you want to call it for user-entered or user-friendly which is common with product management systems. Make sure you index it if used in searching or query criteria.
HTH
While this can't be done completely relationally, you can still normalize your tables some and make it a little easier to code around.
You can have these tables:
-- what are the products?
Products (Id, ProductTypeId, Name)
-- what kind of product is it?
ProductTypes (Id, Name)
-- what attributes can a product have?
Attributes (Id, Name, ValueType)
-- what are the attributes that come with a specific product type?
ProductTypeAttributes (Id, ProductTypeId, AttributeId)
-- what are the values of the attributes for each product?
ProductAttributes (ProductId, ProductTypeAttributeId, Value)
So for a Phone and TV:
ProductTypes (1, Phone) -- a phone type of product
ProductTypes (2, TV) -- a tv type of product
Attributes (1, ScreenSize, integer) -- how big is the screen
Attributes (2, Has4G, boolean) -- does it get 4g?
Attributes (3, HasCoaxInput, boolean) -- does it have an input for coaxial cable?
ProductTypeAttributes (1, 1, 1) -- a phone has a screen size
ProductTypeAttributes (2, 1, 2) -- a phone can have 4g
-- a phone does not have coaxial input
ProductTypeAttributes (3, 2, 1) -- a tv has a screen size
ProductTypeAttributes (4, 2, 3) -- a tv can have coaxial input
-- a tv does not have 4g (simple example)
Products (1, 1, CoolPhone) -- product 1 is a phone called coolphone
Products (2, 1, AwesomePhone) -- prod 2 is a phone called awesomephone
Products (3, 2, CoolTV) -- prod 3 is a tv called cooltv
Products (4, 2, AwesomeTV) -- prod 4 is a tv called awesometv
ProductAttributes (1, 1, 6) -- coolphone has a 6 inch screen
ProductAttributes (1, 2, True) -- coolphone has 4g
ProductAttributes (2, 1, 4) -- awesomephone has a 4 inch screen
ProductAttributes (2, 2, False) -- awesomephone has NO 4g
ProductAttributes (3, 3, 70) -- cooltv has a 70 inch screen
ProductAttributes (3, 4, True) -- cooltv has coax input
ProductAttributes (4, 3, 19) -- awesometv has a 19 inch screen
ProductAttributes (4, 4, False) -- awesometv has NO coax input
The reason this is not fully relational is that you'll still need to evaluate the value type (bool, int, etc) of the attribute before you can use it in a meaningful way in your code.
I need to know if there is any way to have a SEQUENCE or something like that, as we have in Oracle. The idea is to get one number and then use it as a key to save some records in a table. Each time we need to save data in that table, first we get the next number from the sequence and then we use the same to save some records. Is not an IDENTITY column.
For example:
[ID] [SEQUENCE ID] [Code] [Value]
1 1 A 232
2 1 B 454
3 1 C 565
Next time someone needs to add records, the next SEQUENCE ID should be 2, is there any way to do it? the sequence could be a guid for me as well.
As Guillelon points out, the best way to do this in SQL Server is with an identity column.
You can simply define a column as being identity. When a new row is inserted, the identity is automatically incremented.
The difference is that the identity is updated on every row, not just some rows. To be honest, think this is a much better approach. Your example suggests that you are storing both an entity and detail in the same table.
The SequenceId should be the primary identity key in another table. This value can then be used for insertion into this table.
This can be done using multiple ways, Following is what I can think of
Creating a trigger and there by computing the possible value
Adding a computed column along with a function that retrieves the next value of the sequence
Here is an article that presents various solutions
One possible way is to do something like this:
-- Example 1
DECLARE #Var INT
SET #Var = Select Max(ID) + 1 From tbl;
INSERT INTO tbl VALUES (#var,'Record 1')
INSERT INTO tbl VALUES (#var,'Record 2')
INSERT INTO tbl VALUES (#var,'Record 3')
-- Example 2
INSERT INTO #temp VALUES (1,2)
INSERT INTO #temp VALUES (1,2)
INSERT INTO ActualTable (col1, col2, sequence)
SELECT temp.*, (SELECT MAX(ID) + 1 FROM ActualTable)
FROM #temp temp
-- Example 3
DECLARE #var int
INSERT INTO ActualTable (col1, col2, sequence) OUTPUT #var = inserted.sequence VALUES (1, 2, (SELECT MAX(ID) + 1 FROM ActualTable))
The first two examples rely on batch updating. But based on your comment, I have added example 3 which is a single input initially. You can then use the sequence that was inserted to insert the rest of the records. If you have never used an output, please reply in comments and I will expand further.
I would isolate all of the above inside of a transactions.
If you were using SQL Server 2012, you could use the SEQUENCE operator as shown here.
Forgive me if syntax errors, don't have SSMS installed
I have a cube built in SSAS2008 that is built upon 2 tables - Accounts and Payments.
Both tables have dimensions and measures, and it appears to be working relatively well - I can get payments for accounts broken down into dimensions for either payments or accounts, and account measures broken down into account dimensions.
What I can't do is view measures for accounts where a relationship exists with the child payments table. For example, see the balance of all accounts that have at least 1 payment.
I understand I may need a separate cube for this, but I still can't see how my data source would need to be configured.
I'd ideally not like/have to completely reformat the data into a fact / dimension snowflake schema, as I'm not entirely sure how to do this with the relational data I have, however any suggestions on this would be welcome.
Thanks.
Update: Bounty added due to lack of interest...
My answer takes into account that you don't want to reformat your data into a traditional data warehouse schema. If it gets you further down the road then good for you but I suspect you'll run into more of these problems as you grow your project. It might be worth tinkering with how you might transform the data into a star schema before you need it.
I can suggest a few options. The first that comes to mind is to make a degenerate dimension in the accounts cube that is based on the payments fact table. The following example answers your "all accounts that have a payment" problem but this should work for similar questions. I assumed an account statement date as the last day of each calendar month so you'll want to count payments made in each calendar month.
create table accounts_fact
( account_id int not null,
statement_date datetime not null,
bal int not null,
constraint acc_pk primary key (account_id, statement_date)
)
create table payments_fact
( account_id int not null,
payment_date datetime not null,
amount money not null
)
insert into accounts_fact values (1, '20100131', 100)
insert into accounts_fact values (1, '20100228', 120)
insert into accounts_fact values (1, '20100331', 0)
insert into accounts_fact values (2, '20100131', 100)
insert into accounts_fact values (2, '20100228', 20)
insert into accounts_fact values (2, '20100331', 50)
insert into accounts_fact values (3, '20100131', 10)
insert into accounts_fact values (3, '20100228', 30)
insert into accounts_fact values (3, '20100331', 50)
insert into payments_fact values (1, '20100112', 50)
insert into payments_fact values (1, '20100118', 60)
insert into payments_fact values (1, '20100215', 70)
insert into payments_fact values (1, '20100318', 80)
insert into payments_fact values (1, '20100331', 90)
insert into payments_fact values (2, '20100112', 50)
insert into payments_fact values (2, '20100215', 60)
insert into payments_fact values (2, '20100320', 70)
insert into payments_fact values (3, '20100101', 50)
insert into payments_fact values (3, '20100118', 60)
insert into payments_fact values (3, '20100318', 70)
create view dim_AccountPayments
as
select acc.account_id, acc.statement_date,
sum(case when pay.payment_date IS NULL THEN 0
else 1
end) as payment_count
from accounts_fact acc
left outer join payments_fact pay on acc.account_id = pay.account_id
and pay.payment_date >= dateadd(mm, -1, dateadd(dd, 1, acc.statement_date))
and pay.payment_date <= acc.statement_date
group by acc.account_id, acc.statement_date
select * from dim_AccountPayments
This produces the following results:
account_id statement_date payment_count
1 2010-01-31 00:00:00.000 2
1 2010-02-28 00:00:00.000 1
1 2010-03-31 00:00:00.000 2
2 2010-01-31 00:00:00.000 1
2 2010-02-28 00:00:00.000 1
2 2010-03-31 00:00:00.000 1
3 2010-01-31 00:00:00.000 2
3 2010-02-28 00:00:00.000 0
3 2010-03-31 00:00:00.000 1
It should now be a doddle to make a payments count dimension in your accounts cube. For extra points, remove the group by and sum in the view to let SSAS do the aggregation; it suited me to show the results table above. Use the view's SQL in your data source view you don't have create view permission in the source database.
Option 2 would be to make payment count from the view above a measure in the accounts cube. You can do this similarly to the above solution except make your accounts fact use a view similar to dim_AccountPayments. This time you must group by all key fields and aggregate the measures in the database... Very ugly. I don't recommend it but it is possible.
If you go with option 1 then it's simple enough to make a named set in the account payments dimension called 'Made a payment this month' which is children of all filtered to remove 0.
I hope I understood your question. I did have to make quite a few assumptions about your data structures but I hope it's useful.
Good luck.