I am using TADOConn and TADODataSet units pulling data and connected to TDataSources and TDBGrids. I have my DBGrids displaying information properly and editing information in the detail view accurately reflects in the backing database.
What I would like to do is have it so that an update to a field in the detail DBGrid causes a refresh on both data sets so that the most up-to-date data is always displayed.
I have tried putting the refresh calls in several event handlers at various levels of DB access but they all seem to have a similar (but different) issue of reentry.
The best I've been able to come up with so far is getting the Master view updated by calling refresh on the details DBGrid.onColExit event.
If I leave the refresh calls out all together the updated information isn't displayed until the next time the application is run.
Any ideas of how to achieve this? Am I going about it the wrong why? Thanks in advance.
You imply that the changes you make in the DBGrid are posted to the database but are not displayed in the grid or maintained in its dataset and that you must get them back from the database. All the dataset components I have used maintain its copy of the data including all the changes that passed through it to the database. If you expect the data to be changed by triggers or another process, you may need to refresh the data. Then you will have to deal with the possibility that the current record position is lost, i.e. the current record was deleted in the database.
I would try using the Dataset.AfterPost event to initiate the refresh. And I would consider using a Timer to delay the refresh if strange things happen.
Related
I am having a task to Auto Save data after every 5 minutes which is filled in more than one forms however I dont want to save the data in the actual dataset. The main aim of auto save is as there are many fields on the form and the user has typed in details spending his valuable time and during this time if the server goes down then the application would crash thereby loosing the data typed in.
If the application has crashed then next time when the connection takes place then a message should pop up saying "Do you want to recover the lost changes?"
once clicked yes then the auto saved form should be shown.
Just a side note my application is working on datasnap model.
Any suggetions how to go about this really appreciated.
Not sure if this is an option, but perhaps you could deploy the application with a lightweight database (such as SQLite or NexusDB)? If you have a lot of forms with a lot of fields/data, this would make a drafts based solution quite easy to implement.
The idea would be to have a "drafts" table in your local database which is a flat table that will contain and hold all of the data that you want to persist until the transactions are committed to the server database.
Save the data in the forms to this local drafts table (as the user enters them in or on a periodic basis). Once the transactions in the forms are committed to the server database, you can delete the draft record from the local drafts table.
If the app crashes and the user signs back on, you will be able to check the local drafts table and pull the data that you need back into the screen fairly quickly and easily.
Hope this helps.
I have a bigger SAPUI5 application with multiple pages.
If user navigates through all these pages, they will reside in memory of course.
Now I have the problem that some of these pages have a complex context with several bindings to an ODataModel. That leads to the problem that a .refresh() call on the underlying ODataModel take some time.
Because: all known bindings will be reloaded (also from pages not currently shown)
Now I am searching for a better solution to refresh the ODataModel.
The refresh must be done because sometimes a client action triggers the server to updates multiple data (in different models!).
Further information (Edit)
I am using multiple ODataModels in my application and they are created in the Component.js (as suggested in the Best practice chapter of the SDK documentation).
Navigating through the pages will increase the cached data in the ODataModel.
Calling a .refresh() seems to reload all cached data (still used or not).
According to the first reply it is possible to refresh one binding but how to refresh all bindings of a given view/page with multiple models?
Would it be the right way to set multiple instances of the ODataModel for each view? And just call the .refresh() method there? But also on this scenario the locally cached data will increase over time?
Any ideas welcome :)
You can access the binding of a specific UI control and call refresh there. This should just process this specific binding.
My first hint would be to use the v2 OData Model (sap.ui.model.odata.v2.ODataModel), as it uses the Batch Mode by default.
Moreover, when it performs updates, it refreshes all bindings of entities that have been updated automatically so you should not need to refresh the whole model at all.
For me it worked to just re-bind that binding on a specific element in the view as I did earlier to create it at all.
We had an update-problem after another update call had side effects on the information in question, but a refresh on the binding of the elemnt itself did not solve that. I guess there were no local changes to that path in the model, so there was nothing to refresh. But on server-side there where updates the model/Cache didn't know about. Rebinding made my day, and also only the one necessary call to the servcie was made.
I've worked on several iOS apps, some of them utilize Core Data, and some of them don't. While I consider myself having a basic to somewhat good understanding of Core Data, there's always something that makes me doubt the usefulness of it. I've done a lot of reading on the subject, and the general consensus seems to be the advantages of using it outweighs the disadvantages. I recently submitted an app without using Core Data, and always planned on going back to update the project to utilize it when I have the time for some optimization work. Now's the time, but I wonder if it makes sense for the app I'm working on, and maybe I am not using it correctly all along. Please advise and point out what I am missing.
The project I am working on is a social networking app, which also has a front-end site. We have standard features like a newsfeed, event listing, the ability to follow/unfollow someone, and a map with POIs at user's location. Currently, we're using pagination whenever needed when requesting data from server.
My understanding of why Core Data is great:
Easier to manage data with complicated relationship
Easier to access data without having to pass them around
Easier to manipulate, fetch, and sort your data
Better memory utilization
Improve perceived performance by preloading data stored locally until latest data's received
The problem I am having is, since I am using pagination when requesting for data instead of requesting for all at once. The data stored locally is only a subset of the current state in the database. Let's use newsfeed as an example. If I do the following, it will cause some problems:
User manually refresh the newsfeed -> Controller notifies model that it needs the latest 20 items -> Model requests for the latest 20 items in the newsfeed and save them as NSManagedObject -> Model notifies controller that data is ready -> Fetch the latest 20 items to show in UITableView
If user A refreshes the newsfeed, background the app, and then user B deletes his post in the newsfeed (let's say it was 10th item) before user A foregrounds the app again to refresh the newsfeed. In user A's newsfeed, B's post will still be up there because according to the createdAt attribute, it's indeed one of the latest 20 items.
To fix this problem, I can think of a few solutions:
Add a flag to the item to indicate it's removed
Always discard local data when new data arrives
Disable pagination
Instead of using the workflow described above, always present the requested data only instead of fetching the latest
Solution 1 means custom code is required to deal with different clients since browser doesn't need deleted items but iOS client does. However, even though it can work, it can potentially mess up the pagination mechanism and can cause weird behaviours in the client. For example, if a large amount of items gets removed, the latest 20 items will contain only a few items that will actually show up in the newsfeed on the client when user refreshes it. As user follows more people, more stories will be inserted in his newsfeed as well. This solution won't work very well in this situation.
Solution 2 totally defeats the purpose of using Core Data in the first place unless I am missing something.
Solution 3 means the client always needs to request for all data. This is nearly impossible to do because as you get more data, the time to retrieve and process them will make the app slow and unresponsive. It also doesn't make sense from technical and UX point of view.
Solution 4 also kinda defeats the purpose of using Core Data because it's the same workflow when we only store data in memory. You can still fetch and find objects but they might be invalid on the server already at the time of access.
Am I missing something? How is Core Data supposed to be used in this scenario? How do you ensure data consistency when the client doesn't have all the data? Thanks you in advance.
I am looking for a simple way to get data displayed in an issue as just plain text. Basically, I want to be able to type in a lookup id in the issue creation and then once the issue is created, it would call one of our web services to retrieve data connected with that ID.
This wouldn't be coming from another issue tracker, but rather straight from one of my databases.
What would be the easiest way of accomplishing this? I would like the workflow to be: Enter id #, hit save, see the data with that ID displayed in the ticket (Doesn't need to be editable, just displayed in the ticket view).
The easiest way is to create a workflow function that is triggered at Create transition to do the job. There your code can query information from the database and replicate them into JIRA standard and custom fields of the issue itself.
Then you can prevent edition of replicated fields by tuning Edit screen for your issues.
You can also use your function to update field content from time to time, either at transition or in a trigger.
An option is to create some read-only custom fields than query each piece information from the database. It will prevent data replication but it will be probably slow and it does not apply to default fields.
Hello stackoverflow pals.I am a new rails learner. My question is: I am listing all items in index and also i am usin some ajax in this page to insert new items to database. After inserting new items to database, should i get all items from database again and replace whole list of items or just add new item to list by using insert_html? Thank you.
Adding only the new items to the list is likely to be more responsive and will keep network traffic lower. However, it's also going to be a bit more complex for you as the programmer, since you'll have to figure out where to insert it and generally do more management of the table state. But either way can be a valid approach.
If you are keeping track of deletions client-side via AJAX and updating your client's view on delete as well as on insert you should not need to replace all the listings very often. It probably would make sense to poll the server periodically if multiple users are manipulating data at the same time so that one user doesn't end up with a stale view. You should probably look at a Comet implementation like Juggernaut in that case so that the server can push data to the client rather than relying on simple polling.
You also may want to consider beefing up your client-side Javascript and implement pure JSON passing between client and server. This way you only pass the data back and forth from your server to the client and the client's browser keeps the view up to date based on the JSON from the server and the logic you build with Javascript.
If you're at all worried about large amounts of traffic hitting the page, I would push as much as you can to the cilent. Do your insert and update the list accordingly.
If new items always go at the bottom and you can't sort them, I'd just append the new item to the bottom.
If you can sort them or need to insert it in a specific place, I'd re-render the whole table.
Personally, I wouldn't worry about the performance difference until it became a problem; I'd just go with the simplest thing that worked.