I'm working on a project and I need to connect to MS Access Database. The problem is that I'm using a pretty new platform , I'm using Visual Studio 2015 Xamarin and I'm developing to android with c# (thought this platform).
I already have a project with this Database using aspx and i need to connect the android application to this Database .
I could not find any answer for it , probably cause it's new .
Thanks for helping.
The problem is not related only to Xamarin or MS Access.
Everytime you want to use the same database in different applications (in your case a website and mobile apps), it is better to create a new layer (WCF Service or REST API) in order to access the same database on the server. This is more flexible and would be the right thing in your case.
Without moving the architecture to the next Level, you will always have such problems when mixing old and new technologies together.
If you just want to finish this quickly for school and use the database only on the device, then there is no way to use the MS Access database with xamarin. I recommend using SQL lite for this and there are lots of examples for that:
https://developer.xamarin.com/recipes/android/data/databases/sqlite/
It not clear if the database is to run “local” on the android, or you just wishing to connect to some web service that holds the database?
If you needing a local database to run 100% stand-alone on the Android device, then Access is not supported. Your best bet for a local database would thus be SQLite.
Perhaps you don’t need nor want a local data store. In this case if the Access database is on the server, then you would be forced to write some kind of web service to “interact” with your Android software and the web server (this would not be a "general" interface to the database, but a set of web services that you expose on the web site - this assumes you thus have control and are able to write software and implement a web service on the web site. So in this case some kind of “direct” connection to the Access database is not possible.
You could again certainly DIRECTLY connect to a server based database like SQL server – but this would assume the web hosting allows external ODBC connections to the database (often they don’t allow this, but some do).
So not clear is if you need a local database running on the Android that can THEN connect to some web or server based system, or you simply want the android to connect via the internet to some database hosted on some server and the Android device does not have a local database at all.
Regardless of the location of MSAccess, you cannot "connect" to a non server database like Access. So the question remains as to "where" you want this database to be used, and ALSO if you need a local data store on the Android device or not.
Related
I have a disk top application made by c# visual studio. My question is do I have to setup SQL server on each client to use my application? or there is another way to attach my database with my application and compress it as one and send to each client and those just extract that file and use the application correctly?
On a real scenario, your database should be placed on a remote server and the clients should only access the database through your API (that will need to support authentication or any other identity based systems).
If your application only needs to store some local information (relevant only for your client app), then you can just use LocalDB or AppSettings, depending on your data structure.
Otherwise, if your application contains more complex features, then you will need an API and a remote DB managed only by you.
To conclude, you only need to setup Sql Server once, when you want to create the design of it (tables, columns, links). The clients will only have to connect to it and pull their data. And this task can be done without installing SqlServer. This link shows you that you only need System. Data assembly to connect to a Sql Server DB.
Yes you need to instal SQL server on each machine or if you go for LocalDB then also u need to instal SQL server engine ,and you have a better option u need to buy sqlserver from AZURE (it's free for one month try if want click here AZURE)
I wrote an application in c# & SQLite for storing data of all employees in a company which has around 500 employees. I want to put the database & the application in a file server/shared folder (MS server). Then all employees will have a shortcut of the application in their desktops. I want to make some input fields (text box) enabled/disabled based on the permission of the user runs the application. Whats the best practice for doing that?
I want the user can read/write in the database through my application only (the application is located in the same database folder). I don't want the user to reach the database without my application. How to do that?
I don't want the user to reach the database without my application
If your application will directly access the SQLite database via a Windows file share, this is impossible. Sure, you can make it inconvenient, but it's not really possible.
The only way to achieve this really is by introducing some middleware.
This would typically be a service (WCF perhaps) that listens for connections from your client application, authenticates them, and manages all access to the underlying database. The database would be stored in a location that is visible to the server only, and not visible through a Windows share to your users.
Also, SQLite isn't exactly a great choice for a multi-user system. You can kill two birds with one stone here - switch to a DBMS (MS SQL Server Express is free, also MySQL, PostgreSQL are common free choices) that accepts client connections over a network, and build your application to connect directly to the database server (using integrated Windows authentication may also be possible like this, so you can avoid an explicit logon). In a simple scenario this may be adequate and avoid you needing to build an explicit service layer.
In a more complex scenario, it can still make sense to have a middleware layer between the application and the database - this way, you can change the database design without changing the application design and deploying to all of your client machines - instead, just change the middleware layer in one place and your application won't know the difference.
If you don't want the users to reach your database you should create a client server architecture.
You can run your service on the same machine as the file server (running as a Windows Service) and use WCF for communication between your server and your client. You access your database from your server and let your server authenticate your users and validate that they have access to the application.
You can cheat and try to "hide" database credentials inside your client application, but that is security by obscurity and any one with some programming skills or similar can find out the credentials to the database and connect directly to the database.
I've got a question regarding the pros and cons of using a database vs. a flat file in a windows mobile application.
We're developing a mobile application running on Windows Mobile 6.5 and using C#/.NET Compact Framework 3.5.
The mobile component is used in an inventory system to do receiving of deliveries. These data are then sent to the application server using a web service via Wi-Fi.
Now, we need to implement a backup plan. What we agreed so far is when then the mobile is unable to send the data to the server, it has to persist it locally and then send it at a later time. It can either be sent using the mobile or the mobile can be docked/connected to a PC via usb which will pull the data out and the PC can send it to the server.
My question: which is better to use in this scenario? Deploying an SQL Server Compact or writing the data to a flat file (xml, binary etc)
I'd like to get opinions on the pros and cons of each method keeping in mind not only the technical aspects but also the development work involved.
Thanks!
My personal experience with this scenario is to use SQL CE to do Merge Replication instead of a web
service for some very good reasons:
Your application becomes easier to develop because you read/write directly to a database and let the CE engine do the merging. (Linq to Sql etc)
You can manually control merge conflicts at the server or client. And this is already built, you don't have to build it yourself.
There is no backup necessary because your data on the CE device is already in a database.
Data can be cached locally as needed and filtered by device or user (meaning only the data needed by the device/user can be the replicated to the device.)
Although this does require more SQL knowledge, it is solid technology that works, and doesn't have to be re-written, tested and debugged continously.
If you are locked into using a web-service, then using SQL CE seems like overkill to me. I would simply duplicate what a database does and write transactions to a file (xml/json/binary) and then use those as needed (running them against the web-service when in wi-fi range or having a service running on a machine that pulls the files off the mobile device and onto the local PC or server and running those transactions).
We had a requirement to build a ASP.NET 3.5 web application using web forms, WCF, ADO.NET and SQL Server. The users would connect via Internet.
Recently we understood that it is possible that users would often remain disconnected and would have Internet access intermittently.
I need to understand if we can create occasionally connected web application using asp.net 3.5 - what all technologies/features we need to use? Is MS Sync Framework the answer to the problem - is it a viable option to use with web application?
Is windows application the right approach instead of web applications - where the business logic would be run at the client itself, using local SQL Express editions with data then been synced up with Enterprise SQL server at server end when connection is established using replication and/or MS Sync framework. In that case is there a need to use WCF?
Does Silverlight applications help in this context -building paritally connected web apps?
Really appreciate if you can give pointers to how to go about this task of creating .net partially connected apps (not mobile apps)?
It looks to me as if you'll need to store your client data locally when not connected.
If you use wcf you can determine what type of protocol to use according to connectivity without affecting your main code e.g. tcp/ip for LAN, http for internet and msmq for storing up data when disconnected.
If data for transfer is stored up using msmq, as soon as a connection is remade then the data will be passed to your main server.
If you write your wcf, or communications code to run as a service (assuming windows functionality here) then it is up to you whether to retain the asp code or write a new windows app.
edit
Setup MSMQ at both ends, its part of windows setup and can be installed on a client machine, just the same as IIS is, it's on the installation disk but not installed by default.
I wouldn't use it to get web pages, have those available on the local machine, but instead use it to queue up data that MUST get back to the server. Your data access layer should be separated from your GUI layer anyway. I assume that your using the MVC pattern or similar.
I don't know what your application is requried to do but here is the example that I've worked on.
A mobile user who visits clients. He has a replicated copy of a company product database on his laptop. When he visits client sites he may not be able to connect to his company server, but still wants to place client orders. This he does using his laptop based application and database. Order data is queued up in MSMQ on the laptop.
As soon as he is able to connect to his company server MSMQ automatically sends the order data. The server has queued up MSMQ messages of changes to pricing and stock etc. that took place whilst he was disconnected. These are now received and the local database is updated.
The choice of TCP/IP, HTTP or MSMQ all happens seemlessly to the main application, the WCF code copes with the choice.
From what I know, you have two options:
Use Gears (abandoned) or Web Storage to store and sync local data, combined with heavily javascripted web pages that can detect loss of connection and work against the local data store.
Use the Sync Framework with a rich client (WinForms, WPF or possibly Silverlight OOB if it gets supported). The Sync Framework does not require a local installation of a database, instead it uses SQL Server Compact, which is simply a local file.
At this stage using Sync franework with probably rich client seems to be better option. Thanks a lot Guys for taking your time out and trying to answer my queries. I will let you know the technologies used after i manage to deploy the app!
I have a pre-existing desktop application that draws its information from a Microsoft SQL Server. The desktop application is written in C#/ASP/.NET.
I'd like to take this same data and present it in an iPhone application. What would be the best way to obtain and present the data?
I would recommend writing a web service that exposes the data and then interfacing with this from the iPhone across the network.
Calling web services and making HTTP calls is very easy on the iPhone.
Do you assume your iPhone application will have network access? If so I would go the webservice route as already mentioned. If it's a small database that you want available on the iPhone with out the need to access the internet to retrieve data you could look at converting the SQL Server database into a SQLite database and packaging it with your app.