When two users are updating their property details that time their property information are mixed and stored in database.
I have checked source code as well as stored procedure but could not find any solution.
You probably don't have proper rollback procedures... if your database is being accessed in a way that users data is being overwritten you basically need to code your query algorithms or stored procedures better to account for it.
Such as...
//submit data
//check data
//loop
//if not (data) {rollback()}
// submit data
// repeat loop until data is submitted successfully
I've noticed in the code I've looked at that most programmers don't account for this.
I've also noticed that sometimes the data for two seperate records gets assigned the same ID, causing this merging of data
IF I'm way off, sorry, may not have understood the question.
Also, maybe your code that is inserting the data is not functioning properly, so yeah, some of that code would help, as the other guy said. Thanks
Hope this helps.
Related
Hopefully someone is familiar enough with the Drupal 6 Profile module to help me out here. I'm looking at the code but can't make sense of it.
I've set up a bunch of profile fields in different categories and it seemed to be working fine. Then I needed to show the data in a view, but it's just not showing up...only a few fields are.
After a few hours of digging I've discovered that the profile values are being saved to the serialized "data" column in the users table, not to the profile_values table, even though the profile_fields table has fields for all of my new columns.
What's the deal with this? It's killing me...i can't seem to make sense of the logic looking at the module, if I spend the time to write a script to transfer all the data from the user->data column to the proper profile fields table then will it remain there or will it be futile.
Thanks for the help. Pretty frustrated.
OK, finally figured this out. I was really thrown for a loop since it's been working, it must be default drupal behavior to save superfluous data to the user->data object?
Anyhow, I'd used hook_user to add profile forms to the main user edit form but I neglected to run profile_save_profile explicitly on the additional fields on the update operation of hook_user. Have it working now.
The amount of coding that goes into the making of a DataSet is often significant. Now I'm not sure what the industry standard or best practise when dealing with data requests from multiple ASP.NET pages. Should I use a cache/session to pass on the DataSet from page to page or should I fetch directly from the database for each page?
What's the most common approach here?
Here are my thoughts:
It depends on the database and the type of data that you're trying to get, as well as what may modify the data. Do you have backend processes that run concurrent with the data you're going to want? Is this data only updated because of the current page, or does it update at all? How many people are going to use said page?
I personally almost always call to the database, simply because there are so many what-ifs when it comes to this kind of thing. At any time the data can change; it's never as static as people would think it would be. I would personally trade correct data over performance any day.
But that's just me personally. This question is so open ended that it's impossible to take every single thing into consideration since I don't know your database structure, nor how expensive it is to retrieve it, nor what you're using it for.
Sorry I couldn't really be more help.
It depends upon you need. If data size is very large then don't save it in Session or Cahce, because Session or Cache is stored in server Memory. Session is user specific and it will store data for each user in the server, so avoid from it. I think you should directly fetch data each time you need, don't save it in session. If data is very small/limited then you can save it in session ( example UserName or UserId etc ). If you are using a gridview to showdata then use paging and on each page request fetch the data from the database.
I am trying to refine search within the searched results based on rating.
But number of returned results is more than 1000.
So, we have to page them too, and user can sort them too based on rating.
Now, for prototyping I have stored those 1000 results in Session object.
But, is it a good idea. As there could be 1000s of queries, then Session variables would be higher.
Please suggest better / proven ways for this.
Use Viewstate instead of session if you stay on that page and not move data to another page
I would not suggest you to save 1000s records in session object, as when you have more users on your website, your server will be out of memory.
You could use a Stored Procedure to get only the number of records that you want to show in a page.
Get an idea from these links:
http://www.codeproject.com/KB/database/CustomPagingStoredProc.aspx
Stored Procedure for Custom Paging
I'm working on a web application, on one page I am inserting records in the database and I want to display the data in a GridView but on a diffrent page. How can I do this?
I know how to display records in a GridView, but I want to know if there are two web pages,
on one page provides the facility to insert the records and U want to display the records in the GridView bit on the second page.
While it is possible to retain the data being inserted without retrieving it from the database, I think it is better to save the data on the first page and retrieve it from the database on the second page.
You can do this by writing inline SQL or a stored procedure. One simple approach would be to pass the resultset into a DataTable and bind a GridView to that.
That does involve more work -- more code and more trips to the database. However, I think it is very useful when performing INSERTs that the web page is updated to display what actually got into the database. Sometimes, this is different from what the user thinks they entered, and they can see the problem immediately.
One question would be how to identify the data that has just been inserted. I can think of several ways to do that. One is to query for all records entered today by the person logged in (which is recorded in the CreatedBy and CreatedDate columns of the database tables). Sort the resultset in descending order of CreatedDate, so that the most recent entries appear at the top of the GridView. Another would be by assigning a batch number to the data entry and retrieving only the data in that batch.
If you really want to hang on to the data entry, you could put it into Session on the first page, and then retrieve it from Session for display on the second page.
Following along the lines of what DOK said, it's also a lot easier to validate data entered by your users in your business logic before you submit it to the database.
Secondly, users can change their minds about data on a webpage frequently. The data on the web could be in an partially-finished state or could have typos or errors in it. If someone else saw this data and believed that it needed to be completed, then you could end up with duplicated entries in the database that would then require reconciliation.
Honestly, your best bet is to use the Session object to hold temporary user data. The MSDN entry for the GridView RowEditing event contains some great source code for this approach. Whenever I have to use GridViews to handle data from the database, I mimic this.
In addition to handling problems with temporary data storage, you can compare the Session object to your database results to determine whether or not new rows have been inserted. This is somewhat costly as it involves overloading the Equals method (and GetHashCode as well, if you follow what Microsoft recommends) and using Equals to iterate over the two collections, comparing the properties of both objects, and determining which records are new based on records that don't exist in your Session object, but do exist in your database object.
It's also worth noting that this approach assumes that you don't delete data from your database, but set the status of a record in your database to "Deleted" -- if that's a boolean field or an sequence of codes you use to describe the state of rows in a table.
I've searched through the site and haven't found a question/answer that quite answer my question, the closest one I found was: Syncing objects between two disparate systems best approach.
Anyway to begun, because there is no RSS feeds available, I'm screen scraping a webpage, hence it does a fetch then it goes through the webpage to scrap out all of the information that I'm interested in and dumps that information into a sqlite database so that I can query the information at my leisure without doing repeat fetching from the website.
However I'm also storing various metadata on the data itself that is stored in the sqlite db, such as: have I looked at the data, is the data new/old, bookmark to a chunk of data (Think of it as a collection of unrelated data, and the bookmark is just a pointer to where I am in processing/reading of the said data).
So right now my current problem is trying to figure out how to update the local sqlite database with new data and/or changed data from the website in a manner that is effective and straightforward.
Here's my current idea:
Download the page itself
Create a temporary table for the parsed data to go into
Do a comparison between the official and the temporary table and copy updates and/or new information to the official table
This process seems kind of complicated because I would have to figure out how to determine if the data in the temporary table is new, updated, or unchanged. So I am wondering if there isn't a better approach or if anyone has any suggestion on how to architecture/structure such system?
Edit 1:
I'm not sure where to put the additional information, in an comment or as an edit, so I'm going to add it here.
This expands a bit on the metadata in regards of bookmarking, basically the data source can create new data/addition to the current data, so one reason why I was thinking of doing the temporary table idea was so that I would be able to determine if an data source that has been "bookmarked" has any new data or not.
Is it really important to determine if the data in the temporary table is new, updated or unchanged? Do you really need to keep an history of the changes?
NO: don't use the temporary table but just mark as old (timestamp) your old records, don't do updates, and just insert your new data.
YES: your idea seems correct to me but all depends on how much data you need to process each time; i don't think it is feasible with a large amount of data.