I have an ASP.Net website, that uses a MySQL database.
First of all, because the Connect/Net of MySQL doesn't install on PC (reason unknown, no error, it just doesn't work) I'm using ODBC for the connection.
I've written some nice wrapper classes for using the database, and it's all working ok.
But now I'm adding a little Silverlight application to my website (first thing I'm making with WCF/Silverlight, without actually reading any tutorial, so let's hope for the best).
Now this application won't be anything fancy, it's only for the administrators, to read the logs, and change some configuration settings, etc, nothing fancy at all. But what it has to do is retrieve data from the services.
What I've done is a setup a service reference, and it works like a blessing, but now I'm trying to read the logs from the service, and I'm getting in trouble, because my class was never built to serialize to XML, first issue. And secondly I wouldn't know how to bind the retrieved data at the client to the datagrid.
I'm going to parse the recordset at the server so that I'll be sending a class containing an array of columns, and a multi-dimensional with the data to the client, now that's not much of a problem, I'm just mentioning it so that you can either improve or keep in mind what the data will look like.
My question: How would I bind that retrieved data to a plain <sdk:DataGrid>?
You can create your own in-memory DataSet/DataTable without it being hooked up to any particular database. You can populate it yourself using anything you want in the Silverlight application. Bind your DataGrid to it after you've filled it, as you normally would do on a simple client/server ASP.NET application.
Take the retrieved data from the web service, and populate a dataset. Then bind the dataset to the datagrid. You need to write some code-behind code for this, but not much. You can't do it all in the presentation layer's XAML.
(Edit: clarification for client/server/silverlight model)
Related
Hope you can help me get on the right path. I am currently in Design phase of my project. I have a WCF Soap/Rest Web Service that will be consumed by my WPF Client Application. Since the WPF Application needs to work on both Connected and Disconnected State I am having a design problem of how to implement caching.
I am aware of caching during the runtime of the application using ObjectCache but I am wondering in case of the application being closed and re-opened I would like to retrieve anything that the user has already entered as well if the user is disconnected that I can grab last Web Service Response and populate the form? Since ObjectCaching is only while application is up, one way I thought is to have a local database where the client app stores all the data from web service response and user entered/modified data. What I don't like about this option is that I have to duplicate the server database and its tables and data which I don't think is very good practice as well very secure.
Finally, how do you sync all the data? While being disconnected when your finally connected I need to call the WCF Web Service update method and update information back to server. Would this be some type of messaging with a batch job that would run on the client that would know when your connected and reprocess all the data? Any thoughts would be great.
What you're looking for is pretty easy to accomplish, and doesn't require a client-side database. Whether you implement it this way really depends on how secure you need the data to be.
To persist data on the client in a totally disconnected way that lets the user exit and return with no risk of losing their entries, your only option is to store the data on the client. If the application is not able to access the web server to persist the changes, and the application closes or crashes, the changes are lost, and the user is unhappy.
To make this work, create a serializable class or classes that fit your client-side field requirements. The classes need to implement INotifyPropertyChanged so you can bind your UI fields to it and keep the changes inside of the model object (as opposed to the UI controls themselves). Your code behind also needs to implement INotifyPropertyChanged. You need a property that holds the instance of the data object, and this is what you bind your fields to.
As the user types/makes changes, your data bindings have 3 update options: update the property when the user leaves the field, update the property as the text changes, or wait to update the property until after a specified delay time. When these updates occur, the PropertyChanged event is raised. If you attach to this event, you can write a method inside the class to serialize it and save the data as it is entered. A simple XML or JSON file is fine. You also need to add a load method to read the data file, deserialize it, and return the data object. This way, if the application were to close or crash unexpectedly, you would simply call the Load method and set the property in your code behind to the loaded object, the bindings restore the text, and the user can continue.
To keep everything synchronized, the client sends the object to the server so it can validate and save the changes. I would use a field to track data versions (TimeStamp field if using SQL Server) to prevent a client with outdated data from overwriting newer data, especially if you're in a multi-user environment.
If your server is able to take advantage of WCF and Entity Framework, you can build a very robust, reliable application very quickly.
As far as security goes, that depends on the type of data being entered and the legal requirements behind them (I.e. Credit cards and PCI compliance), so you would have to address those individually.
I've got an ObservableCollection which is binded to my LongListSelector.
User can add items to it by form in my app - all data saved in list are serialized.
I want to add few items to my app, that will be present after installation. User can delete and modify them, like any other items.
What is the best way to do that? I don't think that creating multiple objects in code is good idea.
Local databases are what you need. They would even be helpful later of you plan to persist the changes user has made.
Windows Phone Silverlight has nice LINQ-to-SQL support with SQL server CE. Here's the information you'll need to implement databases: http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202860%28v=vs.105%29.aspx
If you prefer app walkthrough, here it is: http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh202860%28v=vs.105%29.aspx
You will need to deploy a reference database and copy it to isolated storage since you want user to have some data prepopulated. Here's a nice reference for such scenarios: http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh286411%28v=vs.105%29.aspx
Edit: You can, of course, use external XML, but it has its fair share of problems like this.
In my project I am getting all the required data to List and using that List other functionality like
List1.AddRange(list.FindAll(s => s.PortfolioID == ClientList[i].PortfolioID));
to check data and fill a gridview.I am updating that list only when the data is saved.
It's working fine with one user. But the problem is when the users are more.
Like User1 ,user2 logged in as administrator and Client
and Administrator changed data,since user2 (Client) is getting data when he logged in, he can't get the changes which admin has changed recently until he saved data or relogged in.
I have used this concept in entire project.
To do better functionality, I have two ideas:
Getting List in Load event.such that for evry operation it
will get entire list of data
Changing entire code to take directly from Database instead of from
List.
I thought first one is good but I am not sure how much data can WCF services can handle. If the data is more, then there will be a problem for entire functionality. If WCF can handle more data i will use first one.
For the second one, I have to go to server for every functionality.
I am new to WCF and ASP. I need your help.
Please suggest me what to do?
WCF services can handle more data than your users can handle, so I would use WCF and your option 1.
I have a client who has a product-based website with hundreds of static product pages that are generated by Microsoft Access reports and pushed up to the ISP via FTP (it is an old design). We are thinking about getting a little more sophisticated and creating a data-driven website, probably using ASP.NET MVC.
Here's my question. Since this is a very small business (a handful of employees), I'd like to avoid enterprise patterns like web services if I can. How does one push updated product information to the website, batch-style? In a SQL Server environment, you can't just push up a new copy of the database, can you?
Clarification: The client already has a system at his facility where he keeps all of his product information and specifications. I would like to refresh the database at the ISP with this information.
You don't mention what exactly the data source is, but the implication is that it's not already in SQL Server. If that's the case, have a look at SSIS.
If the source data is in SQL Server, then I think you'd want to be looking at either transactional replication or log shipping to sync the two databases.
If you are modernizing, and it is a handful of employees, why would you push the product info out batch style?
I don't know exactly what you mean by "data driven", but why not allow the ASP.NET app to query the SQL Server product catalog database directly? Why generate static pages at all?
UPDATE: ok, I see, the real question is, how to update the SQL database running at the ISP.
You create an admin panel so the client can edit the data directly on the server. It is perfectly reasonable to have the client keep all their records on the server as long as the server is backed up nightly. Many cloud and virtual services offer easy ways to do replicated backups.
The additional benefit of this model is that more than one user can be adding or updating records at a time, making the workforce a lot more scalable. Likewise, the users can log in from anywhere they have a web browser to add new records, fix mistakes made in old records, etc.
EDIT: This approach assumes you can convince the client to abandon their current data entry system in favor of a centralized web-based management panel. Even if this isn't the case, the SQL database can be hosted on the server and the client's application could be made to talk to that so you're only ever using one database. From the sounds of it, it's a set of Access forms and macros which you should have source access to.
Assuming that there is no way to sync the data directly between your legacy system DB (is it in Access, or is Access just running the reports) and the SQL Server DB on the website (I'm not aware of any):
The problem with "pushing" the data directly into the SQL server will be that "old" (already in the DB) records won't be updated, but instead removed and then recreated. This is a big problem with foreign keys. Plus, I really don't like the idea of giving the client any access to the db at all.
So considering that, I find that the best is to write a relatively simple page that takes an uploaded file and updates the database. The file will likely be CSV, possibly XML. After a few iterations of writing these pages over the years, here's what I've come up with:
Show file upload box.
On next page load, save file to temp location
Loop through each line (element in XML) and validate all the data. Foreign keys, especially, but also business validations. You can also validate that the header row exists, etc. Don't update the database.
3a. If invalid data exists, save an error message to an array
At the end of the looping, show the view.
4a. If there were errors, show the list of error messages and tell them to re-upload the file.
4b. If there were no errors, create a link that has the file location from #2 and a confirmation flag
After the file location and confirm flag have been submitted run the loop in #3 again, but there's an if (confirmed) {} statement that actually makes the updates to the db.
EDIT: I saw your other post. One of the assumptions I made is that the databases won't be the same. ie, the legacy app will have a table or two. Maybe just products. But the new app will have orders, products, categories, etc, etc. This will complicate "just uploading the file".
Why do you need to push anything?
You just need to create a product management portion of the webpage and a secondly a public facing portion of the webpage. Both portions would touch the same SqlServer database.
.Net has the ability to monitor a database and check for updates. then you can run a query to [push] the data elsewhere.
or use sql to push the data with a trigger on the table(s) in question.
Is this what you were looking for?
You can try Dynamic Data Web Application.
You should have a service that regularly updates the data in the target DB. It will probably run on your source data machine (where the Access-DB is)
The service can use SSIS or ADO.NET to write the data. You can do this over the web, because you have access via TCP/IP to the server I assume.
Please check when the updates are done and how long it takes. If you can do the updates during the night you are fine. If not you should check, if you can still access the web during the import. That is sometimes not the case.
Use wget to push the new data file to the mvc app and once the data is received by the action, the mvc app invokes the processing/importing of the data (maybe in a worker process if you dont want long requests).
i know this is an age old question, but this is my scenario
This is in C# 2.0
Have a windows application which has a datagridview control. This needs to be populates by making a webservice call.
I want to achive the same functionality on the data if i were to use a direct connection and if i were using datasets, namely like paging and applying filters to returned data. i know returning datasets is a bad idea and am looking to find a good solution.
I might look at ADO.NET Data Services, aka Astoria, in VS2008 SP1.
This allows you to expose data over a web-service (WCF exposing ATOM, IIRC) - but you don't need to know all these details: the tooling worries about that for you: you just get regular IQueryable<T> sources on a data-context (not quite the same as the LINQ-to-SQL data-context, but same concept).
The good thing here is that a LINQ query (such as filtering (Where), paging (Skip/Take) etc) can get composed all the way from the client, through the web-service, and down to the LINQ-enabled data store (LINQ-to-SQL or Entity Framework, etc). So only the right data comes over the wire: if you ask for the first 10 rows (of 20000) ordered by Name, then that is what you get: 10 rows out of the database; 10 rows over the wire, no messing.
Write a custom class (MyDataItem) that'll hold your data. Then you can pass a List<MyDataItem> or some collection of MyDataItem and bind to your grid.
Paging, filtering, etc. would need to be implemented by you.
There is no way to get the binding behavior you automatically get with a DataSet if you are going through a Web Services data layer. You would have to create your own proxy class that supports all the databinding functions and persists them through your web service calls. Depending on your application's environment, you may want to batch up modifications to avoid excess round trips to the web services.
fallen888 has it right - you will need to create a collection class of List or a DataTable, fill it with the output from the webservice data stream, and handle paging and filtering yourself yourself.