I'm overtired and need to do one last thing on my data base that wasn't expected in the beginning. I have a table that I assigned passwords to employees. I hashed them right away. Now what I'm told to do is have the one column retaining the original passwords but (I already created a new column for the new hashed passwords) now I'm told keep those but in the new column have them hashed. so the 'password' column keeps the original passwords and the 'hashedwords' will have a displayed column of the hashed passwords. My brain is mush right now and I'm messing up trying to figure, what I believe to be a simple update.
Let me see if I can word this again...
table has multiple columns. in it are two columns, one with original passwords (called "passwords" and a new column with nothing in it (called "hashedpasswords").
How can I create a statement that reads the original passowords and keeps them there, but will update the 'hashedpasswords' column with... hashed passwords?
I apologize if this being worded weird. I've been sick and am trying to catch up on work. I keep thinking this should be really simple but just can't get the statement correct. Please help.
in this example, the table is called 'users'...
i just found out i dont have enough reputation to post a pic of the example... darn it I hope this is enough to make sense.
Related
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.
you most probably going to think "what an idiot" but remember i never done any type of coding before so this is all new to me,
My problem are that i'm working on a HUGE excel sheet with loads of data that is not needed. i need to sort the data into a few columns, i only need column "A,K,AN,AQ" but in column "AS" i only need certain values (yes,no,blank) i only want the yes and blank values. like i said never done any coding before but i know that you can use an macro to do it so please help, how do i go about this?
before trying to get into macros, try to use functions with if else statements. They are quite easy to handle. Like: If (yes) then put it into X. Later, you could select all needed. Also, check the, how the dollar sign is used
use this links to see, if it is something for you.
One quick and dirty way of getting this job done would be to:
Delete the columns you don't need.
Select all cells in the range you're interested in, click the Insert menu, and choose "Table". If your columns have titles, select the box for "My Table has Headers."
-This turns your data into an array so that Excel recognizes that each row is an entry (instead of thinking that the cells are unrelated).
Now you can use the filter icon in the column headers to select and display only the rows containing the values in column X that you're interested in.
Note that there are some limitations to what the table feature is good for, so, as always, whether this is a good solution for you depends on what you want to do with the data.
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 :)
In an alternate application, the user has the ability to update their address and phone number. When these are changed, three fields will update: Old Value, New Value, and Field Changed. If the Field Changed was the address, I need to create two report pages - one with the old address and one with the new. However, if the Field Changed was the phone number, I only need to create one report page for the current address.
My initial plan was to do a Union that would have one record with the Old Value and another with the New Value. This should work when only the Address has changed. However, it won't whenever the Phone Number has changed. I assume I need to do some sort of case statement, but I'm not really sure if this is the right approach. Sorry if the data is a little confusing (I didn't design the data structure. This was provided by our professor's assistant). If you need more information, I'll try to provide it.
I'm not looking for exact SQL, but I am wondering if I'm approaching this the correct way.
What do you mean by a 1 or 2 page report? Are you outputting to a CSV, PDF, XLSX or something eles?
If you need to do this through "pure" sql I would recommend a stored procedure that is given a value stating whether it's the address or phone number that is being updated. It can then do the update and you can simply do an if statement which determines which report to run and return.
I'd recommend handling it programatically if possible. Have your code run the sql update and then call the appropriate function within your code to get the report you need. You can then easily re-use the code for that report in other ways.
I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use #DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a #DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using #DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the #unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
Foo|id1
Bar|id2
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the #DocumentUniqueID for alias can be a good idea under some circumstances.
It depends on where your using the data. The #DBLookup or #DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the #DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using #GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using #DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. #Unique is pretty good for this, and gives a shortish key, if that is important to you. #DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "#DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.