Not sure how, but an MS Project individual ID line data (not Unique ID) has jumbled itself up.
Not sure how it happened, need to reorder the Id back to the sequentional numbering system.
Any thoughts
Jumbled up IDs
The tasks have be sorted by a field other than the ID. To change this back, look for the Sort option on the View tab and select "by ID".
See Sort tasks, resources, or dates in Project desktop for more information.
Related
SHORT VERSION: If all else fails, add a value (even zero) to an additional Number column in the SQLite table to stop the #DELETED demon.
LONGER VERSION: There have been many posts about this frustrating and inconsistent problem over the years. Lord knows, I have read each one at least half dozen times and tried every remedy proposed - and usually one of the incantations will finally solve the problem. Yet I found myself recently in a new quandary and spent the last two days racking my brain to osmose why none of the tricks worked on it.
It was classic: Access 2019 front end linked to a SQLite back end table (via the Devart SQLite ODBC driver, which I believe is inconsequential). The table had the recommended col_ID of Number format, Auto-incrementing as the Primary Key. It had col_DateUpdated, Text format with default value of current_timestamp. There was col_OperatorID which was Text format and the only column in a Unique Index. Finally, there were two other non-indexed Number format columns.
The table worked fine in SQLite. I could Add, Delete, Update no problem. In Access, when I opened the linked table and added a record it did not immediately show the auto incrementing value in col_ID, nor the date/time stamp. When I clicked off the row, it immediately filled all the columns of the new row with #DELETED. If I closed the table and reopened it, the new row would display just fine.
The SQLite Pragmas were all set to Default including Auto Index, Normal Locking Mode and Full Synch. I tried every combination of changing the table structure, column formats, indexes, default values, etc. The problem persisted regardless of whether there was any other data in the table or not.
I've been coding in Access for over 30 years and SQLite for three and have never seen anything like it.
I was stumped until , for the heck of it, I added a value into one of the other Number columns. Amazingly, it worked great!
I can create a new row, put values in col_OperatorID AND the two non-indexed Number columns, click off the row and it takes it fine. It updates the autonumber primary key col_ID and col_DateUpdated with the current date/time just fine with no #DELETED nonsense.
It beats me why it works, maybe Access finally can accept it as a really, really unique record (even though the additiaonal data is not in any index) or maybe putting the numeric value in the other, seemingly unimportant, columns forces an update across the link, I don't know. But I thought I would pass this along because I KNOW probably forevermore, unless Microsoft or the SQLite folks come up with a cure for this, there will be people that will need this additional gimmick to get out of #DELETED hell.
Good luck and Happy Trails.
I have searched throughout stackoverflow looking for a way to generate numerical keys or any type of keys that are readable for the end user.
I have found multiple answers saying (you shouldn't). I get it .. but what's the alternative..
Imagine a customer having an issue regarding an Order for instance and having to spell the uid 1UXBay2TTnZRnbZrCdXh to your call center?
It's usually a good idea to disassociate keys from the data they contain. The data can change, usernames, passwords, locations etc. That kind of data is very dynamic. However, links and references are more static in nature.
Suppose you have a list of followers and you're using their username as a key. If a user changes his username, not only will their entire node have the be deleted and re-written, every other occurance of that key in the database would have the changed as well. Wheras, if the key is static, the only item that changes in the child username.
So to answer the question: here's one option
orders
firebase_generated_key_0
order_number: "1111"
ordered_by: "uid_0"
order_amount: "$99.95"
firebase_generated_key_1
order_number: "2222"
ordered_by: "uid_1"
order_amount: "$12>95"
With this structure you have the order number, a link to the user that ordered it and the total amount of the order. If the customer changes what's on the order, a simple change the order_amount is done and the order stays in place.
Edit:
A comment/question asked about race conditions when writing data with Firebase. There are a number of solutions but a good starting point is with Firebase Transactions to essentially 'lock' data to prevent concurrent modifications.
See Save data as transactions for further reading.
I'm looking at accepting a project that would require me to clean up an existing e-commerce website. Its been relatively successful and has over 100,000 individual products - loaded both by the client and its publishers.
The site wasn't originally designed for this many products and has become fairly disorganized.
SO, the client has asked I look at a more robust search option - filterable and so forth. I completely agree it needs to be improved, but after looking at the database, I can tell that there are dozens and dozens of categories and not everything is labeled correctly etc.
Is there any database management software that could help me clean up 100,000 entries quickly? Make categories consistent - fix uppercase/lowercase problems etc.
Are there any companies out there that I can source just this particular part of the project to?
Its a massive amount of data-entry. If I spent 2 minutes per product, it would take me 6 months full time to just to complete the database cleanup. I either need to get it down to a matter of seconds per product or find a company that specializes in this type of work.
I don't even know what to search for on Google.
Thanks guys!
--
Thanks everyone for your ideas! I have a lot of options now so I feel a lot more comfortable heading in to this project. Right now I think the direction we will go is to build a tool that allows the client to hire data entry people that can update it as necessary. Then I will work as a consultant, taking care of any UPDATE-WHERE type functions as necessary.
Thanks again!
If there are inconsistencies like you are describing, it sounds like the problem may be more an issues of a bad data model (i.e. lack of normalization) than just dirty data. If good normalization is in place, cleaning up categories should be as simple as updating a single record per each category - but if category name is used instead of a foreign key, then you will most likely need to perform a series of UPDATE WHERE statements to clean up the text.
You may want to look into an ETL (extract, transform, load) tool that can help with bulk data transformation. I'm not familiar with ETL tools for mysql, but I'm sure they exist. SQL Server has a build in service called SQL Integration Services that provides the ability to extract data from an existing data source, perform bulk changes or transformations, and then reload the data back into a destination database. Tools like this may help speed up the process of standardizing capitalization, punctuation, changing categories etc.
Even still, don't overlook the possibility that the data model may need tweaking to help prevent this type of situation in the future.
Edit: Wikipedia has a list of opensource ETL products that you may want to investigate.
In any case you'll probability need to do more than "clean the data", which means you'll need to build new normalized tables. So start there, build a new database that is fully normalized, import the data "as is", with all the duplicate categories, etc.
for example, new tables:
Items
ItemID int identity/auto number
ItemName string
CategoryID int
....
Categories
CategoryID int identity/auto number
CategoryName string
....
import the bad data into the new system:
Items
ItemID ItemName CategoryID
1 thing A 1
2 thing B 2
3 thing C 3
4 thing D 1
Categories
CategoryID CategoryName
1 Game
2 food
3 games
now, you can consolidate the data using the PKs
UPDATE Items
SET CategoryID=1
WHERE CategoryID=3
DELETE Categories
WHERE CategoryID=3
You might just write an application where the customer can do the consolidation. Let them select the duplicates on a screen and merge to a selected parent category. you have this application do the merge sql from above.
If there are issues of needing to have a clean cut over date, create an application that generates a series of "Map" tables, where you store the CategoryNameOld="games" and the CategoryNameNew="Game" and use these when you do the conversion/load of the bad data into the new system's tables.
I would implement the new search system or whatever and build them a tool that would allow them to easily go through and cleanup the listings, re-categorize, etc. This task requires domain knowledge, so they're the best ones to do it.
Do some number crunching so they can prioritize the list and clean in order of importance.
Keep in mind that one or your options is to build a crappy interface that somebody can use to edit records, hire half a dozen data-entry people from a temp agency, spend two days training them, and let them go to town.
I'm currently writing a posting website that needs to have a version control on posts. I just don't know how I should implement this, in term of database and technique, in order to save and control the post.
Is there anyone experienced with this who can help me?
I've seen that Wordpress does version control only in 1 table, which is POST. I also suggest doing the same since it's trouble to write into 2 tables with the same amount of data and fields.
I know that stackoverflow stores deltas between versions. What I have seen others do is set up another table like the first one but with an author and a version or timestamp on it. You can push records over to the other table using a database trigger so you don't have to worry too much about making the change at the application level.
If you would like to use only one table then I would suggest adding the author, timestamp and a iscurrent flag. The flag isn't really needed since you can select the max version number but it will make your queries much easier. Set the flag only when the row is the highest version number. You can still use a trigger to populate the rows but watch out or you might end up in a loop of update triggers.
I would create two tables, one is "live version" table and the other is an "archive" table. When a new version is created, move the existing live version to the archive table (with appropriate timestamps and author notes) and add the new live version to the live table.
The archive table would have the same schema as the live table except that it would also have additional columns that would hold metadata about the versioning that you are supporting (version number, notes, timestamps, etc.).
Take this with a huge grain of salt, but, you could have a parent id that is joined to the primary key on the same table along with a bool that indicates whether its the current version. It's the method I used for a CMS system a while back... You might want a common id for a revision history (so that getting all historic entries for an item is non recursive). You could do this by including the first version's id with the all the subsequent versions so you could get the whole lot easily.
my .02
Sounds like you just want a record version number on the row. It's a number that identifies the latest version. Every time you update the data you actually insert a new row and bump the record version number. When you query to get the data, you just query to get the row with the max record version number. Triggers can be used to generate the record version number so you don't have to worry about generating the number when inserting.
If you want to go full-blown version control, you need some sort of status field on the row as well that tells you if this version is reverted/deleted/approved or not. When you get the latest, you select the the row with the max revision control number that has the appropriate status.
If you just want to save the history of the posts and not actually have revision control you can just use the record version number technique.
See also Implementing Version Control of DB Objects.
I have an asp.net/vb file that receives data and processes it via a stored procedure. The code had the width set to 2 for the year's varchar, so it was chopped, leaving only the first two digits to get inserted into the db.
Is this info possibly retrievable from a system/IIS log file or is it lost forever?
thanks!
That data is lost forever.
Do you have data that isn't corrupted? Are the records in the database sequential or do they have automatically incrementing fields. Do you have timestamps on the records? Do the years correspond to the date when the record was inserted/updated? Depending on your answers to these you may be able to reconstruct the data. In particular using timestamps and/or autoincrement fields may give you the ability to determine a particular ordering between records. If the date field is related to this ordering you may be able to infer the year from the data in other records. It's very unlikely that any log files would be of any use.
Only if the year was part of a querystring or URL...which is unlikely, at best. If your IIS admin happened to turn on logging of POST fields, then you may be able to retrieve it from there. Very few sites that I know of, though, ever log POST data.