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.
Related
I apologize if the question asked is simple and far too stretched out
I've been studying the fundamentals of SQL Injection attacks and at a point, I've read that a potential method of verifying the data type of a particular field in a UNION SQL Injection attack is by making certain changes to the request that we make to the target server.
The software being used is BurpSuite, and the target is a practice lab on the website https://portswigger.net. It is told that the category field is vulnerable, and that the query for the category returns two fields, so the following "code" is appended to the category part of the HTTPS GET message that we send to the server in an attempt to know the data type of the first field
...?category=Gift'+UNION+SELECT+'abc',NULL+FROM+table_that_contains_target_information--
According to the manuals for the lab, what we're doing with the 'abc',NULL part is that we're verifying that the first field in the "table_that_contains_target_information", is of the type string/varchar. This seems to work and aids one in determining the data type of that particular field, as I checked in the lab, since if the first field's datatype is not a string/varchar, I would get an internal server error.
However, later on, when performing a query on a general database to check what the 'abc',NULL part does in a general SELECT query, the results that come are somewhat different.
The general database question is one that is available to use for learning SQL at https://www.w3schools.com/mysql. It has a table named Customers with several fields. I know for a fact that the first field is an integer (via verification with information_schema.columns), and the rest are varchars. For context, in the Customers table, CustomerID is an integer field, and CustomerName is a varchar field. I ran the following query on the server
|-------This part is the original query-------||This is our inserted code to find out information about the database|
SELECT CustomerID, CustomerName FROM Customers UNION SELECT 'abc',NULL FROM Customers
Disclaimer: My intentions were not to cause any harm to the database, only to learn some SQL
According to what I've learnt from the Lab manuals, I should be getting an error of sorts right?, since I'm checking the datatype of a field in a method that and unethical hacker could potentially take. However, all I get are the results of the original query and an extra record with values 'abc' and the second field is NULL.
I've tried to read up on documentation regarding the SELECT query in SQL, but as far as I was able to find, most of them tell about the general SELECT * FROM table_name or SELECT column_name, other_column_name FROM table_name. I wasn't able to find anything about the SELECT 'abc' FROM table_name.
Could anyone please explain what is going on here? Does the SELECT 'abc' FROM table_name just give me an extra record with 'abc'? If so, then why is this same query used to verify the datatypes in the lab at https://portswigger.net, and it seems to work its purpose there.
Thank you for answering in advance!
This is very strange even for my limited knowledge of Access. Background information: I am making a database which track the people I work with. The boss wants a report with the people leaving and the people replacing them, so I though this may work. However when I join the information, it results in the checkbox showing a NULL value. I made sure to set the default to NO and it is not set up for a triple state checkbox from what I can tell.
This is just a sample of what it would look like:
Table
I am using the fields IDReplicate and Replacement ID in order to JOIN the table and query. IDReplicate is just a copy of the Primary Key. Using the primary key as the first field in the JOIN produces a type mismatch
My query to pull information about the replacement people:
SELECT tblExample.IDReplicate, tblExample.Arrival, tblExample.City, tblExample.Package, tblExample.LName
FROM tblExample;
My query to which joins the people leaving and people arriving:
SELECT tblExample.LName, tblExample.Departure, tblExample.ReplacementID, qryReplacement.*
FROM tblExample LEFT JOIN qryReplacement ON tblExample.ReplacementID = qryReplacement.[IDReplicate];
Resultant Query Datasheet
It sounds like you may have a three-state checkbox where you want a two-state, check this SO post for details:
Determine whether a Access checkbox is checked or not
IMO, checkboxes are trouble and best avoided. My advice would be to change the field to a text field with a constraint to limit entry to yes or no, defaulting to no. That way you know exactly what data is really in your table, instead of counting on Access to translate an interface element into data. If you do it in the Access table design interface it would look something like this:
I have to build this retail site, and aparently all the properties info comes from a third party company. Everything looked fine, they sent me a .mdb file with all the tables (which convert to a .sql file), and later I get emailed with data to update those tables.
What confused me was the fact that a few of these tables already have values in them. And when looking at the documentation, it says that I will also get emailed 'dictionary tables'. It says: "These tables contain fixed values in reference to value tables".
I have googled and searched here at stalkoverflow but couldnt find an answer. What I read was something about 'sas' and 'proc sql' which I haven't heard before.
Could someone please explain me (or kindly point me to some understandable documentation) what this tables are (are they in fact tables?), and how can I use them to build my site? I also use Codeigniter, can I use active records on them? Or what would be the correct SQL to access that table? I'm pretty much lost here :(
I use Codeigniter 2.x and Mysql.
Thanks guys, I will be infinetely grateful for your help.
Two guesses:
a data dictionary provides information about tables in a database:
field names, field types, field sizes
stored procedures associated with certain tables
OR
simply a fixed table that provides lookup or validation for a separate updatable table.
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.