I have data like "00000973456, 973456, 00006589234, 6589234 etc.." kind of values in X col (len:11), in my table, while I am trying to update table data using these values : 00000973456 & 00006589234 and it is working fine.
But how to Update using values without zero's in front (973456, 6589234) though the length of these values are different.
Can anyone help me with the code to update using both type of values.
Click here for Image example
Related
I would like to color a cell based on the header and row values, not the cell value. In the sample below, when [ship_prom] = [produced_month] the [sum(wgt_scaled)] cell should go green (marked by X in the example).
[produced_month]
[ship_prom] [Sum(wgt_scaled)]
201812 201901 201902
201901 2.1 X 3
201902 1.5 X
Sorry if formatting doesn't work - tried pasting in an image but that failed too..
I tried conditional formatting of [Sum(wgt_scaled)] using =iif(Fields!ship_prom.Value=Fields!produced_month.Value,"Green","No Color")
but not all cells have values, and every null value cell turned green.
Additional from DonD:
The actual report has several additional fields / groups, so your comment around it being in that area is appropriate. I tried to simplify the report to just the basic data but still am not getting the same output as you.
reduced report info
#steve-o169 Since you are able to produce the report using the Switch, I'll go ahead and mark your answer as best. Thanks for the help!
design layout example
sample desired output
Actual data query and subset of data
Looks like you just need to add another conditional statement to account for NULL values. But personally, I would suggest implementing a switch for better control. Try the following expression.
=Switch(Fields!ship_prom.Value=Fields!produced_month.Value AND TRIM(Fields!ship_prom.Value) <> "","Green",
true, "No Color")
EDIT: Might need to see the query before I can really figure out the problem at hand here. I'm unable to reproduce your issue. I've created a simple dataset with the following query.
CREATE TABLE #temp(ship_prom INT, produced_month INT, wgt_scaled DECIMAL(2,1))
INSERT INTO #temp (ship_prom, produced_month, wgt_scaled)
VALUES (201901, 201812, 2.1), (201902, 201812, 1.5), (201901, 201901, NULL),
(201902, 201901, NULL), (201901, 201902, 3.0), (201902, 201902, NULL)
SELECT * FROM #temp
I've laid out my table with a column group on produced_month and a row group on ship_prom and grouped by ship_prom with the following layout.
Using the exact switch expression from my answer, I was able to achieve the following result.
I am trying to pull only part of the value from one column: "CI_Support_Remarks" to update another column "Asset_Number" in my table "CI_Information". If the data is currently stored as:
"Asset#: 33800000125Primary support:Persons nameSecondary support....ect"
How do I only pull the number following "Asset#:" and nothing else to update the Asset Number column. I am only trying to update the Asset column and not affect the CI_Support_Remarks column.
As a note all the asset numbers are the same length and stored in the same format.
Thanks
Just use substr():
update t
set asset_number = substr(CI_Support_Remarks, 9, 11);
I am attempting to maintain and fix a horribly out-of-date CRM designed by an ex-employee ~4-5 years ago in Access 2007. I have brought it into Access 2013 and fixed a ton of stuff up, but I am still running into many problems.
I spent a good 4 hours today attempting to figure out why certain values didn't line up. These values were being pulled from a SELECT statement on a Combo Box over a stored Query which simply returns a table with a few extra rows. Great.
However this value (a number) doesn't appear to correlate with what we expect. I enter in one value, save the ticket, and a completely different value gets stored into the table. Opening up the ticket, I see the value that I expect. Digging deeper, I found the following difference:
Set value_1 = Me.RegistrationID // What's being stored in the table
Set value_2 = Me.RegistrationID.Column(0) // What we expect
Surprise surprise! This is a Combo Box and some value is being stored in the table. The Control Source is "RegistrationID" and the Row Source is the query in question.
However I do not know what it is! This specific value correlating to the Combo Box appears to pull the correct data when we later open the tickets. However I have a strong feeling that this could be why many tickets from before one of the rows was deleted all appear to have invalid RegistrationID's.
How badly can this break?
How easily can we correct tens of thousands of tickets?
How can I fix this to store the correct value?
This is what I expect is happening.
Your combo box row source is based on a Select query which returns and displays multiple rows. For example:
Select RegistrationID, CustomerID, CustomerName From MyTable;
The Control Source for the combo box is bound to RegistrationID which is part of the Forms Record Source.
The issue is the bound column. If we set the bound column in our example to 1, then we get the behavior your are describing with:
Set value_1 = Me.RegistrationID - Set's value to CustomerID (may appear correct)
Set value_2 = Me.RegistrationID.Column(0) - position 0 from our query (RegistrationID)
Further building on our query example, you can say:
Me.TextBox1 = Me.RegistrationID.Column(0) - RegistrationID
Me.TextBox2 = Me.RegistrationID.Column(1) - CustomerID
Me.TextBox3 = Me.RegistrationID.Column(2) - CustomerName
The RegistrationID is what normally should be stored in the table.
As long as your form shows any values that directly relate to this RegistrationID you're fine.
I would start by checking to see under the format setting to see if column widths are set properly and I would also check under the data section to see if the bound column is correct. I might also throw in an after update macro/vba sub routine that saves the record. Hope this helps.
I have a basic Table called ReceiveReport which contains the fallowing fields ID, Units, GrossWt, NetWt, TareWt. I allow the user to select his units (lbs, kgs) afterwards he has to enter gross/net/tare weight into the fields. I want the fields to update them self depending on the unit field. I tried using the After Insert Macro, but I couldn't use SetField which made me confused about how to update the field.
I want to do something fairly basic.
iff([units] = "lbs", [field]*2.2046, Do Nothing )
am I going at this the wrong way?
You could update the value in a Before Change macro like the following. The approach I chose leaves the [units] and [weight_entered] values intact and updates a separate field named [weight_kg], but you could also overwrite the values that were originally entered if that was your preference.
I have a table with rows and where one field is a bit-value with 7 digits.
Suppose I have a procedure where I want to select all rows where this bit field equals '0101010', this is easily done by select * where .... and so on.
But: how do I do if I want to allow one/multiple digits of the digits to be either 1 Or 0, i.e I want to get all rows where the bitfield has an entry on the form 1001*1* where the * can be either 1 or 0. So, in this case I would like all entries where the bit field is 1001010, 1001011, 1001110 or 1001111.
select * from TABLE where bit_field in (1001010, 1001011, 1001110, 1001111) would probably work in this example, but if I want to use only the string '1001*1*' as input to the procedure, what then?
.
Any help is very appreciated.
Thanks,
Niklas
Edit: I've tried this: select * from table where field like bit'\\\0'; for getting all entries of the form **0, but that didn't work...
Edit2: It turned out it vas a bit-field, not binary... problem still remain though.
Not a direct answer to your question, per se', but an alternative approach. You mentioned that you didn't want to convert to individual columns because of legacy code. If you do want individual columns and the only thing holding you back is the legacy code, consider the following.
You could add columns for the options and use insert/update triggers to populate them OR you could create a view that splits the bits into separate columns. For new development, you can code to the new columns. Over time, as you modify legacy code you can change it to the new approach. When all the "read" legacy code has been changed, the last step is to change the "write" code to use the new columns rather than the bit column and remove the triggers.
I have a SQL Fiddle demonstrating this here. Note that I only included an insert trigger for brevity.