I'm experiencing something strange when joining SQL tables.
Let's say I want to output an image for each result where
tableA.FullNameA = tableB.FullNameB
I am entering the data in table B with a php form. To my human eyes, the names I have are identical in both columns. However, it does not detect a match. If I then manually go into the db and copy and paste the name from tableA.FullNameA to tableB.FullNameB (and when it is overwritten, there is no discernible change to the text) then it miraculously matches and my join is successful.
Is this something to do with encoding of the data when it is added to the DB? I have never come across this before - does anyone recognise this issue?
Thanks in advance for your help.
Related
Here's my situation. We have an application that uses sybase to store it's data on the back-end.
Please refer to my screenshots below for better understanding of what I'm talking about.
In our application, we have some custom "tabs" (columns in the db) which are supposed to contain data on the db tables. When opening and viewing in the application, these tabs contain data (so they must reside somewhere...), however when you query the table they're supposedly residing under, there's no data to be found. These columns should not contain all null values!
In this example, "trainer" is one of the columns which should contain data. I do a [sp_columns #column_name = 'trainer'] and see that it supposedly resides under table "user_tab_data" (screenshot 1).
Expanding user_tab_data in our sql browser, we see the data points we need to query (training date, training course, trainer, etc.), however when querying for the values, nothing comes up! We can see when opening the application that there is indeed data stored somewhere though.
Is there anything I can do to locate this? Am I missing something here? Any help is appreciated.
Thank you
sp_columns to find table name
query showing that table contains null values
Well this is embarrassing. I figured it out. There was just so many entries on the table that you could scroll for hours and not see any entries where the columns I wanted had any data.
I had to do 'is not NULL' to pull only the ones I wanted to see.
Duh.
I am having an issue with my Microsoft Access database. One of my tables looks completely blank, but it has 11632 records listed in the bottom. Take a look at this screenshot. Though the table shows up blank, when I run the query it pulls the correct data from this table, so I know the data is there, it is just not appearing for some reason. I have tried on Access 2013 and 2016 on a different computer, and both have the same effect. I have also tried compacting and repairing, and also exporting the table but the file it exports to also appears blank, aside from the field names. Any ideas on what I could try?
Thanks!
Turn your import into a 2 step process (or more...). Write it raw into a scratch pad table. Then fire an append query, that has the appropriate criteria to result in only valid records going into the final table.
This isn't unusual at all given that some outside data sources may not have the controls to prevent bad records. Sometimes one must "wash" the data with several different query criteria/steps in order to filter out the bad guys.
I have a table I imported from excel. Everything was imported as strings to get started and gradually the data types were fixed.
I am now going through the process of normalisation and to start I done a select distinct on a given row to extract out the columns that were repeated to another table with an id.
Now I am trying to replace every occurrence of the string in the original table, with the id of the corresponding string in the other table.
I can do it one by one with something like this no prob...
UPDATE myTable
SET myCol = REPLACE(myCol, 'String', 'Num')
and later convert the myCol to an int.
But having to run this, and various variations on it for every string in the system is very error prone.
For example, if I accidently use the same number twice, replacing every string...I cant tell anymore which recordset originally belonged to the first update, and which were the new ones. This is a problem when the dataset is as large as mine.
Is there some way I can combine this with a join on the tables and have the system automate the process for me. I can imagine with normalisation being such a big thing for the last 30 or more years, this issue must have been met and resolved by now.
Any help would be appreciated.
Folks,
I have what should be a simple one, but I'm have few concerns about the performance.
I have a spreadsheet that gets data from a crystal report and uses that to derive some supplier information. If the date received is incorrectly entered into the source system we can unfairly "black mark" the supplier, so we update the data in the spreadsheet, but obviously this gets overwritten daily.
I have some code that archives off any updates, but after a refresh I'd like to put that back.
So, where Tab1.A$1 = Tab2.A$1 AND Tab1.A$2 = Tab2.A$2 AND Tab1.A$3 = Tab2.A$3 AND Tab1.A$4 = Tab2.A$4 AND Tab1.A$5 = Tab2.A$5
then I need to update Tab1.A$6 = Tab2.A$6
I could probably fathom this out, (I'm a DBA rather than a programmer), but the way I'd do it would involve looping through the Tab1 and then for each line loop through Tab2, swapping of tabs etc and is probably a very poor way of doing it. Is there a better way?
Cheers
Mike
Just to understand this question correctly, can you please let me know if I am getting it right.
As I understand you are foucusing on updating the 6th(rows that are different) row of a sheet to match the other sheet's 6th row if all other fields matches. Am I correctly understanding this ?
If So why don't you copy all the data from one sheet to another ?
From another point of view, if the tab to be updated consists of a subset of objets (say supliers), then it cannot be done in a static manner....
Can you please explain little more may be with an example ?
EDIT: Please read my answer below first, before you decide to read and try to understand the text below. You may not find it's worth it when you see what was going on ;)
I have a weird problem: SQL Server 2008 R2 keeps complaining about an invalid column that is indeed not there anymore, but I'm not using it either!
I can't update any rows in that table anymore from within my own application, where no reference to the column can be found, because I always get this error now.
I then wanted to update straight in SSMS as a test, but when I edit the rows there, I still get this error.
What happened before: I made a column called CertcUL varchar(1), and that worked. After a while it appeared I needed it to be a varchar(30), so I edited the table design and turned it into a varchar(30).
From that moment I saw that I could only update this column when I stored 1 character. When I tried to store more, I got an error warning me about string or binary truncation. So somehow, the previous varchar(1) info was still present in the DB.
When I renamed that column to CertcUL2 or Cert_cUL, the same things kept happening! So changing the column name does not change the underlying cause. Also when just trying to add some characters straight in SSMS.
When I deleted the column, and added a new one with varchar(30) straight away, and called 'test', the same problem remained! This column still only allows me to store one character! The column was the one but last column. Making it the last column does not help either. Only when creating an new column while keeping the other column, I can have columns that behave properly.
So somehow, SQL Server saves some meta data about a column, even when it has been deleted. And does not look at the name, but rather at the order in which the columns are created.
Does anyone have an idea how this can happen, and how I can fix this besides (probably) dropping and recreating the whole table?
Thanks!
Oh my God I feel so stupid...it's a trigger that still contains this column. I just noticed it because when trying to update with an update statement. Only this way I got a proper error message, so I now know what's going on. So stupid that I didn't check the triggers! Sorry about that!
More info: I had an update trigger on this table A, that copies all current values to a history table B that contains the same columns. So I did change the length of the column CertcUL in table A, but forgot about table B. So it was very confusing to see the old column name popping up every time, and see it complianing about string truncation while my column in table A seemed just fine.
Sorry again :)