I am new to SharePoint development. I have a list, this list has a column that is called Todaysdate. This column needs to be updated daily to today's actual date and since it contains ~20,000 rows I am NOT going to update it manually everyday. Because it's used in a calculation row.
My question is can I just use SQL and update the rows in the UserData table that correspond to the datetime column that I need?
I can query the list of rows by something similar to
Select * from UserData where tp_ListID = 'GUID'
but the data contained in the column datetime3 is not just the Todaysdate information. How do I return just the Todaysdate info?
You really should not query let alone update the SharePoint content database directly using SQL. It is totally unsupported, so if you break something you are left alone, and the database schema may change with future service packs / releases.
Also as noesgard mentioned it in his comment you do not need it to use today's date in a calculated field, see this blog entry on how you can do that.
Related
I am currently entering data into a SQL Server database using SSIS. The plan is for it to do this each week but the day that it happens may differ depending on when the data will be pushed through.
I use SSIS to grab data from an Excel worksheet and enter each row into the database (about 150 rows per week). The only common denominator is the date between all the rows. I want to add a date to each of the rows on the day that it gets pushed through. Because the push date may differ I can't use the current date I want to use a week from the previous date entered for that row.
But because there are about 150 rows I don't know how to achieve this. It would be nice if I could set this up in SQL Server where every time a new set of rows are entered it adds 7 days from the previous set of rows. But I would also be happy to do this in SSIS.
Does anyone have any clue how to achieve this? Alternatively, I don't mind doing this in C# either.
Here's one way to do what you want:
Create a column for tracking the data entry date in your target table.
Add an Execute SQL Task before the Data Flow Task. This task will retrieve the latest data entry date + 7 days. The query should be something like:
select dateadd(day,7,max(trackdate)) from targettable
Assign the SQL result to a package variable.
Add a Derived Column Transformation between your Source and Destination components in the Data Flow Task. Create a dummy column to hold the tracking date and assign the variable to it.
When you map the Excel to table in a Data Flow task, map the dummy column created earlier to the tracking date column. Now when you write the data to DB, your tracking column will have the desired date.
Derived Column Transformation
I need to add every day to some query result a column A for sysdate, and next day as well, and next day as well, etc.
So you will have the same select which will always add for new day a new column for actual date.
Is this somehow possible in sql without using INSERT, UPDATE and other rewriting statements?
Thank you very much for your answers :)
Im using a Oracle SQL Developer
SQL queries give you a fixed number of columns and a variable number of rows. If every day means more data to you then you would have a query to result in more rows usually. It's up to a GUI to display retrieved data in the most convenient way (one column per day in your example).
So, yes and no. Yes, you can (very easily) write a query to give you more data each day. No, you cannot write a query that results in a new column every day. But as mentioned, this is not what SQL is made for anyhow. SQL is the data retrieving language. You use a programming language or a report tool to display the data to your users.
I have a table with a bunch of different fields. One is named period.
The period is not part of the raw data but I run a query when I import new data to the database that gives each record a period.
Now I need a delete query that will delete all the records that have the same period as what is selected in a combobox.
The values in the combobox come from a calendar table that contain all the possible values that could be in that period column at any time.
This is the basic query i thought would solve this issue but it tells me it is going to delete 0 rows every time I run it:
DELETE *
FROM PlanTemp
WHERE PlanTemp.period = Forms![Plan Form]!Combo163;
If you don't need the key field, just remove it.
Look at the "PROPERTIES" section and look at the column names.
Ether remove it there, or from your QUERY source.
You can also look at the Data section of the properties, and change your BOUND column, to Column 2... or whatever holds the data you want to use.
I have problems with my records within my database, so I have a template with about 260,000 records and for each record they have 3 identification columns to determine what time period the record is from and location: one for year, one for month, and one for region. Then the information for identifying the specific item is TagName, and Description. The Problem I am having is when someone entered data into this database they entered different description for the same device, I know this because the tag name is the same. Can I write code that will go through the data base find the items with the same tag name and use one of the descriptions to replace the ones that are different to have a more uniform database. Also some devices do not have tag names so we would want to avoid the "" Case.
Also moving forward into the future I have added more columns to the database to allow for more information to be retrieved, is there a way that I can back fill the data to older records once I know that they have the same tag name and Description once the database is cleaned up? Thanks in advance for the information it is much appreciated.
I assume that this will have to be done with VBA of some sort to modify records by looking for the first record with that description and using a variable to assign that description to all the other items with the same tag name? I just am not sure of the correct VBA syntax to go about this. I assume a similar method would be used for the backfilling process?
Your question is rather broad and multifaceted, so I'll answer key parts in steps:
The Problem I am having is when someone entered data into this
database they entered different description for the same device, I
know this because the tag name is the same.
While you could fix up those inconsistencies easily enough with a bit of SQL code, it would be better to avoid those inconsistencies being possible in the first place:
Create a new table, let's call it 'Tags', with TagName and TagDescription fields, and with TagName set as the primary key. Ensure both fields have their Required setting to True and Allow Zero Length to False.
Populate this new table with all possible tags - you can do this with a one-off 'append query' in Access jargon (INSERT INTO statement in SQL).
Delete the tag description column from the main table.
Go into the Relationships view and add a one-to-many relation between the two tables, linking the TagName field in the main table to the TagName field in the Tags table.
As required, create a query that aggregates data from the two tables.
Also some devices do not have tag names so we would want to avoid the
"" Case.
In Access, the concept of an empty string ("") is different from the concept of a true blank or 'null'. As such, it would be a good idea to replace all empty strings (if there are any) with nulls -
UPDATE MyTable SET TagName = Null WHERE TagName = '';
You can then set the TagName field's Allow Zero Length property to False in the table designer.
Also moving forward into the future I have added more columns to the
database to allow for more information to be retrieved
Think less in terms of more columns than more tables.
I assume that this will have to be done with VBA of some sort to modify records
Either VBA, SQL, or the Access query designers (which create SQL code behind the scenes). In terms of being able to crunch through data the quickest, SQL is best, though pure VBA (and in particular, using the DAO object library) can be easier to understand and follow.
In my Access database, I have a table called customers. In this table I have a column called DateEntered. The data type for the field is short text.
The values in this column are not coherent - they come in several variations:
MM-DD-YYYY,
MMDDYYYY and
MM/DD/YYYY.
There doesn't seem to be any standard set.
My goal is to select all customers from 2012. I tried
select *
from customers
where DateEntered <('%2013') AND >('%2012');
but it comes up blank when I run it.
Can anyone point out what I'm failing to do correctly & more importantly explain why exactly this query doesn't work in Access? From my understanding of SQL (not very advanced) this should work.
Another variant)
select * from customers where RIGHT(DateEntered, 4) = '2012'
If you have control over the database and application code, the best way to handle this is to use an actual Date field instead of text in the table.
One way to handle this would be to add a new field to the table, write a query or two to correctly convert the text values to actual date values, and populate the new field.
At this point, you would then need to hunt down the application code the refers to this field in any way and adjust to treat the field as a date, not text. This includes your insert and update statements, report code, etc.
Finally, as a last step, I would rename the original text field (or remove it altogether) and rename the new date field to the original field name.
Once you fix the problem, querying against the field will be a piece of cake.
Alternatively, if you can't alter the table and source code, you can use the date conversion function CDATE() to convert the text value to an actual date. Note that you may need to guard against non-date entries (NULL or empty string values, as well as other text values that aren't really dates in the first place). The IsDate() function can be your friend here.
If you have the time and patience, fixing the data and code is the better approach to take, but sometimes this isn't always feasible.
Why don't you use LIKE operators (they're appropriate when you have a pattern using % and _):
select * from customers where DateEntered like '%2013' or DateEntered like '%2012'