In my BO universe there I intentionally left out contexts.
Now when I select measures from multiple fact tables I get following error msg:
Incompatible combination of tables
Show details gives:
Error:
com.businessobjects.semanticlayer.qt.QTException: The query cannot run because it contains incompatible objects. (WIS 00008)
Cause of Error
The query cannot run because it contains incompatible objects. (WIS 00008)
Cause of Error
Incompatible combination of tables
(btw - in the universe I have checked out the option "multiple SQL statements for each measure", which WAS checked by default)
Does anybody now how to resolve this error?
Second point - since I have intentionally removed contexts, that means there should be no loops in the data foundation. Right?
That also means that I should use Alias tables to remove every loop. Can somebody confirm this assumption?
And the last point is - I have 2 fact tables, and when I take both of them in the query panel, then I get one query -> one result. However I have additionally 2 fact tables, and when I take either one of them or both of them, I get 2 or 3 queries. Why is that happening, and where can I turn off generation of multiple queries? Thx!
Problem solved by (1) using alias tables, and (2) unchecking "multiple SQL statements for each measure"
Related
I am trying to merge tables several tables so that I can impute the missing data in the final table.
But, I am always getting the duplicate column 'column name'.
What I did is :
I did Innerjoin several tables and aliased every derived table . And used it
Its an assignment work, so can't share much details, but need be I will try to change variables and share the code.
Would be glad if some one has experience on this error handling?
We are working with WEBIs that have been released from a Universe modified from the standard Epic released universe and have to make a few small changes to the SQL code behind the WEBIs
The fields joined are still the same data type and none of the fields in the SELECT or WHERE clause have changed, but for some reason we get this error code when we press the Validate button 'The data type of a column in the query is not valid. (IES 10811)'
Anyone have advice on what else I can troubleshoot? Thanks in advance!
Modified Code aliases X_CLARITY_SER using a table with the exact same data structure called CLARITY_SER_2
INNER JOIN CLARITY_SER_2 X_CLARITY_SER_800 ON >(V_LOG_BASED.PRIMARY_PHYSICIAN_ID=X_CLARITY_SER_800.PROV_ID)
LEFT OUTER JOIN ZC_PAT_SERVICE ON (X_CLARITY_SER_800.SERVICE_DEFAULT_C=ZC_PAT_SERVICE.HOSP_SERV_C)
Original Code
INNER JOIN X_CLARITY_SER_800 ON (V_LOG_BASED.PRIMARY_PHYSICIAN_ID=X_CLARITY_SER_800.PROV_ID)
INNER JOIN ZC_PAT_SERVICE ON (X_CLARITY_SER_800.SERVICE_DEFAULT_C=ZC_PAT_SERVICE.HOSP_SERV_C)
The error means that the datatype of one of the universe objects doesn't match the datatype of the database column. That shouldn't happen in your case, in which you're changing to another table with the same structure. I'm wondering if maybe one of of the objects in the universe has an incorrect datatype -- that is, the problem is present regardless of your SQL change, but it is just noticing the problem when it tries to parse the SQL.
I would do an integrity check in the universe. That will identify any incorrect datatypes. I'm assuming you've double-checked that two tables really do have an identical structure, but might be worth checking again.
Finally, as a brute-force method of debugging, I would just start removing objects from the query (and the associated column in the SQL) to find the one causing the problem.
For me, the solution was to refresh the source tables in the Universe Designer.
BO chose types of columns with a date in a wrong way (as character columns) and that's why columns types of my new table didn't match.
EDIT:
I met with such problem as mapping varchar columns in a database vs. date columns in BO also with an error "Unexpected behavior" (IES 10901) (FBE60502) when I wanted to send emails with BO publication.
I have two table:
Table: Options
Options
Id xItems
- ItemA,ItemB,ItemC,etc
Table: Items
Items
Id
-
I am attempting to delete all Items rows that are not listed within Options.xitems
I attempted to execute the SQL statement
DELETE FROM items
Where items.id NOT IN (SELECT xitems FROM options)
However the problem is that multiple values are contained within XItems and I only managed to delete rows where Item.Id was the first or only value.
Would appreciate any kind help
EDIT: The following update added from the OP's post as an Answer.
The server is MySQL(tags edited accordingly) which allows one to enter an SQL statement below to execute against any database table or tables. I am a front end dev and get confused with this stuff.
John, I ran the code you posted. Here is the acutal code I applying against backedup test tables
DELETE FROM xbak514q_ecom_prodoptionsel
WHERE NOT FIND_IN_SET(xbak514q_ecom_prodoptionsel.id, (SELECT xprodoptionsel FROM xbak514q_ecom_prodoptions))
which returned the following error:
A problem was encountered while executing the SQL statement submitted.
The error was reported as: The MySQL extension encountered a problem
submitting an SQL statement. MySQL reported the error as: Subquery
returns more than 1 row
This database was configured by a software company who set up an e-comm site. The Items, Product options and selection items(add ons) are quite extensive. Should I consider reformatting the tables?
Again thanks for your kind help
have you tried using find_in_set()??
DELETE FROM items
WHERE NOT FIND_IN_SET(items.id, (SELECT xitems FROM options))
FIDDLE DEMO
NOTE:
find_in_set() is only for MySQL but since you have it tagged for both this may or may not be the solution. however the function looks for a comma separated list that is a single string or item and takes the first argument as the search string
RECOMMENDATION.
you should NEVER store data in the database as a comma separated list like that.. it causes HUGE issues in the future. please consider normalizing your database. if you want a way to do that just post a comment and I'll write up a query that will normalize it for you.
I have a table in the database with the following columns: ID, Name, Txt. We are using Linq To Sql to implement our DAL. In there another collegue added two extra columns so in the code the same table results: ID, Name, Txt, NameTemp, TxtTemp.
These two "fake" tables are used in different parts of the code in LINQ joins and analyzing with SQL Profiler the parsed SQL query takes the "real" columns and everything works properly.
Now I need to make an INSERT using that table, but I get an exception since also the fake columns are used in the statement.
Since I cannot add the two fake columns in the DB(since unuseful there), is there a way in which I could make an insert with Linq omitting these two columns?
I think i know where you're getting at. You should be able to add properties to a partial linq class no problem, only thing is that if you try and use a linq query against these "fake" columns, you'll get an exception when linqtosql tries to reference a column that doesn't exist in the database. I've been through this before - i wanted to be able to select columns that don't exist in the database (but do in the linq2sql dbml class) and have linq2sql translate the columns into what they really are in the database. Only problem is that there's no real easy way to do this - you can add attributes to the "fake" properties so that linq2sql thinks that NameTmp and TxtTmp are in fact Name and Txt in the sql world, only problem is that when it comes to inserting a record, the translated sql specifies the same column twice (which SQL doesn't like and throws an exception).
You can mark the column with IsDbGenerated = true - that'll let you insert records without getting the double column problem, but you can't update a record without linqtosql complaining that you can't update a computed column. I guess you can use a sproc to get around this perhaps?
I logged a bug with Microsoft a while back, which they'll never fix. The info here might help you get what you need -
http://social.msdn.microsoft.com/Forums/eu/linqtosql/thread/5691e0ad-ad67-47ea-ae2c-9432e4e4bd46
https://connect.microsoft.com/VisualStudio/feedback/details/526402/linq2sql-doesnt-like-it-when-you-wrap-column-properties-with-properties-in-an-interface
LINQ is not for inserting data, but for querying only - Language INtegrated Query. Use ADO.NET for inserting the data.
(Leaving the first part to remind my stupidity)
Check ScottGu. The classes generated are partial (mentioned here), so you can put your 2 properties into the editable part and since they won't have any mapping attribute defined, they won't be mapped nor persisted.
Note: If you're looking for a solution to your own problem and you were drawn here, it will probably not help you. Unless you're analyzing one SQL query for the bug when in fact the bug might exist in a query that follows it, unbeknownst to you, this question can be of no help to you. I'm just warning you now, because none of the data provided in this question actually leads to the answer.
In order to extend a database table regular_rules without modifying the table itself, I have created an additional table (extended_rules) whose PK is also a FK to regular_rules. I can then place any new columns in extended_rules, then any time I load up a record from it I just need to join it with regular_rules in order to treat it as though it's the full object. Thus, as you can see, these two tables share a one-to-one relationship.
However, regular_rules also has a one-to-many relationship with another table (rule_coupons), which also needs to be joined.
Thus, I have the following query:
SELECT `main_table`.*, `primary_coupon`.`code`, `regular_rules`.*
FROM `extended_rules` AS `main_table`
LEFT JOIN `rule_coupons` AS `primary_coupon`
ON main_table.rule_id = primary_coupon.rule_id AND primary_coupon.is_primary = 1
LEFT JOIN `regular_rules`
ON `main_table`.`rule_id` = `regular_rules`.`rule_id`
This looks perfectly fine to me. However, I receive the following error message:
SQLSTATE[42S22]: Column not found: 1054 Unknown column 'main_table.rule_id' in 'on clause'
Through testing, I have found that this error is occurring on the second join, despite that I've successfully accessed main_table.rule_id just moments prior in the very same query. Interestingly, if I swap the two joins, the error still occurs on the second one, which leads me to believe it may not be a logic error but rather a syntax one, pertaining to something that I simply don't understand yet.
Please note that I do not have the luxury of modifying the first join (onto rule_coupons), and that I may only modify the second join (onto regular_rules) or add new parts to the query.
Edit: Interesting development... If I paste the query into phpMyAdmin and execute it there, it works fine. I also tossed together a quick, basic PHP script to execute the query using mysqli, and that worked fine. So far, it seems to only happen within the scope of the platform upon which I'm building (Magento). I've been working with Magento for a long time and I've never come across a strange database issue like this before... So I'm still not sure what's wrong, but at least now you have a bit more context.
Just a guess: Try to omit the table alias and set brackets around the ON clauses:
SELECT `extended_rules`.*, `rule_coupons`.`code`, `regular_rules`.*
FROM `extended_rules`
LEFT JOIN `rule_coupons`
ON (extended_rules.rule_id = rule_coupons.rule_id AND rule_coupons.is_primary = 1)
LEFT JOIN `regular_rules`
ON (`extended_rules`.`rule_id` = `regular_rules`.`rule_id`)
If this should work, then it is a bug I have observed several times: MySQL seems to have a problem if you're using aliases for some tables but not for all. Otherwise, just ignore what I've written ;-)
As it turns out, I had tracked this problem down to the wrong spot in the code.
As you can see, the SQL is intended to return a collection of results, as the purpose of that query is to populate a grid. The error occurred whenever I tried to load that grid. Unfortunately, I was unaware that someone else was performing another query for each row that was returned by my query.
Once I realized this, I looked into that second query and therein was the source of the problem. This also explains why it appeared as though the error always occurred on the "second" join in the query, no matter what it was... the error was simply occurring after the query I was analyzing!
All of this is to say, the information I provided in the question could not possibly lead to the answer, as I was incorrect to start with. I apologize to anyone who tried to figure out the answer and wasted their time.