I wrote a Stored Procedure that retrieves parameters from my dropdown list and a txtbox that I use for my where like % clause I got everything to work except for the 'Where like clause' It looks like it should work but obviously it doesn't. Any help would be appreciated.
ALTER PROCEDURE [dbo].[SearchEmpRecords_Sp2]
@SearchBy varchar(50) = '',
@SearchVal varchar(50) = ''
DECLARE <a href="/Members/value">@Value</a>
Thanks for your help but, I don't know what to put in blah blah blah. I'm very new at this. The only thing in my code that doesn't work is the 'Where Like clause' If you could give me more details I would appreciate it. Thanks
Ok. I'm trying to replace the Username or State or AreaNumber with 1 of those values when selected from web form. I got the ''%' +likeValue + '%''' part to work. But I would like to do the same thing for the three options via: Username,State or AreaNumber. In my code above I'm using @Value because I think it's holding the value when selected from web form. But when I run my program I get my custom message that 'No records Found' Please refer to my example code above for reference.
Is it possible create/configure MySQL for functionality like SQL Server's Linked Server? I'm using MySQl v5.5 and I need to link postgreSQL Database to access some data. If yes, would you please tell me how?
I was taught to model one-to-many relations using an intermediate 'link' table to maintain 1NF.
However I'm increasingly seeing one-to-many relationships modelled simply by concatenating the 'many' into a single string and storing that directly in the table.
Consider a table of TASKS, and a table of CATEGORYs, where each task may have multiple categories.
I was taught to model the relationships between the tasks and categories using a third table, eg TASK_CATEGORIES, which comprised a one-to-one mapping.
Task_ID Name Allocated_To etc
1 Fix XYZ Bug Dan ...
2 Add ABC Feature Dan ...
Cat_ID Name Description etc
1 Bug This is a bug ...
2 Feature This is a feature ...
3 Work This is a work item ...
Task_Cat_ID Task_ID Cat_ID
ie. The task: (Task_ID == 1) has categories: (Bug, Work), etc
Well for a start your foreign key potential is out the window, it makes your use of category basically useless from a data structure POV.
I have seen it once, a project built by Reuters, one of the worst performing applications ever inflicted on us. The only benefit was to make the structure so obscure it was unusable by anyone without the ER diagram.
 I now remember one of the new devs proposing that a while back, offered to terminate him on the spot unless he conformed to a correct data structure [/edit]
Never underestimate the power of human stupidity RAH
#2 is obvious violation of 1nf. Whenever there is a need to add or remove a category in #2, we will have to read and write the whole table. That is a serious design flaw. In #1, we can use task id and categorg id as composite primary key for the intermediate table.
hi friends actually i am working on a mlm project in which members are added in a tree pattern, and get the payment accordingly.
My table structure isas follow:
Id ParentId IsLeft IsRight
1 Null Null Null
31 Null 1421 Null
52 Null 1631 Null
73 Null 1841 Null
94 Null 11051 Null
the problem is that initially 1500$ are given to parent when two nodes are added to its left and one to his right(2:1) . and then 500$ for each pair.
My problem is to find the query which can return the total income of any given node.
enter image description here
According to figure node 1 must get 2500$ (1500+500+500) first 500$ isfor node 4 and second 500$ isfor node 3.
According to figure node 2 must get 1500$ because it has two nodes to its left and one node to its right this means a ratio of (2:1). and has no pairs
According to figure node 3 must get 0$ because it does not have any nodes in ratio(2:1)
one thing has to be kept in mind that 1500$ will be the first payment and then only the other pairs will be counted, and 1500$ will be given when node has ratio 2:1(two nodes on left and one on right) but no money when ratio is1:2(one node on left and two on right)
I have found the query which will count all the pairs below a particular node and give receiving amount according to 500$, but the query has not been able to consider the first condition that is the 2:1 condition
declare @ParentId asintset @ParentId=1
create table #temp_table_name
ParentId varchar(30) null,
;with Child as
select id,ParentId from tblTestingTree where id=@ParentId
Select tblTestingTree.Id,tblTestingTree.parentId from tblTestingTree
inner join Child
insert into #temp_table_name
select c.ParentId from tblTestingTree T join Child c
WHERE ISNULL(T.ParentId, 0) <> 0 and c.ParentId!=@ParentId
group by c.ParentId
select COUNT(*)*500 as totalmoney from #temp_table_name
drop table #temp_table_name
Use SQL Server Management Studio to build the queries you need to get the results to meet your needs. I cannot do your job for you. If it is too hard to work out how to use this code then get another job, this one will be beyond you!
Never underestimate the power of human stupidity RAH
But I'm not going to tell you how. And this is why: Pyramid schemes are illegal in a larger part of the world, and I'm not being part of it! Alternatively this is a school assignment, where I'm not simply going to tell you the answer. Because I'm might have to work with you in the future, and if you got your degree without actually having understood what you were taught, you're going to be a dead weight for your workmates.
So you'll have to do the work yourself, but I'll assume you're a student and will give you a few pointers on how to get there.
Drop that silly tbl prefix, you're not selling furniture and it's not following standards (ISO-11179). Drop the temp table, it's a last resort and shows that you're thinking procedurally instead of setbased.
So if you think setbased instead: get two CTEs, one containing the nodes having left children and one having containing the nodes with right children. Now you only need to join those CTEs three times to get the nodes that should get payed $1500.
Politicians are always realistically manoeuvering for the next election. They are obsolete as fundamental problem-solvers. Buckminster Fuller
Last Visit: 31-Dec-99 19:00 Last Update: 27-Feb-17 6:36