Assume that I have a third-party database application with SDK that can be used to retrieve data out of the database in XML.
On the other side, I have developed a website using Laravel framework of PHP. The website is supposed to display data from the database of the application.
In regards to above I have the following questions:
As far as I understand, I can either store the requested data in my website database or just show it without storing. What technique do you suggest?
How do I achieve xml data transfer from the database server to the website?
Taking into account that I have experience of development in C#, I assume that I have to develop some web-service that would run on the database server, retrieve the required data and send it to my website. So the web-service has to receive the requests from my Laravel website, retrieve data from database server accordingly and pass the xml response to my website that would finally display it. Am I on the right way? If so, could you please guide me on how to code and bind these parts?
Thank you in advance.
I have to agree with #Serge in the comments - there are many ways to do this because it is a very broad question.
My answer was mostly going to deal with how regularly the third party database was going to be updated but judging from your comments, I'm assuming it will be fairly often? In which case, I would likely connect directly to the third party database from your laravel app using the firebird driver found here: https://github.com/jacquestvanzuydam/laravel-firebird (Please note, I have never used this so I cannot comment on it's quality) instead of writing a C# web service. I don't know much about firebird itself but you will likely want to connect using an SSH tunnel or VPN for security reasons.
Then I would either store data in MySQL if you know it isn't likely to change very often (in this case you would use a laravel command, run on a schedule, to pull data out of firebird every [X] days/hours/minutes depending on the data) or, if the data is likely to change on each potential web request, using some form of caching system (redis, memcache, file cache etc) to speed up the web requests.
Sorry if that isn't particularly helpful - if you can provide more information maybe I can help you out further :)
Good luck!
Related
I have created two applications using Visual Studio and C#.
The premise of the applications is for data entry and browsing of the data. However, I have come to the realization that these applications won't work on other devices as the data source is a local Access database. Am i able to somehow share these apps with others without giving them the Access database too? This is a major problem as my boss only wants these apps and not the database to be sent with them too. Or would I have to migrate the database to an SQL server and try to migrate the application as well?
Thank you
TLDR:
Can Access database applications be shared across desktops?
Yes
Am i able to somehow share these apps with others without giving them the Access database too?
Yes
Or would I have to migrate the database to an SQL server and try to migrate the application as well?
Not necessarily
It's a difficult question to answer because the question seems slightly confused
You've created an app or two that enters and shows data in an access database, and now you're asking if the app can be distributed without the Access database
Sure it can; but what then will be the purpose of the the app?
You ask if it could be switched to using sql server instead.
Sure it can, but I'm not really clear on how you think it will help because you then have to install sql server in the customer premises and give them the database. I suppose you could keep the sql server on your premises and they could connect to it, but then you could just as easily create a web service or API that sits in front of your access db and have your programs interact with the API, as a way of keeping databases off the customer premises and then stick with Access (or change it later and not affect the customers because you're providing the same api which a new db).
It's most typical, when having software that customers use and a database that you keep ownership of, to separate them with an api
As an aside, Access is terrible in a multi user configuration where two different apps are trying to use the same db file I've a file share; take any steps you can to avoid using this scenario
Stackoverflow is designed to answer particular kinds of questions and there's a real risk that this question will stray into opinion based territory and become off topic. We can't design your app for you, we can only help with implementation problems but it sounds like you need to sit back and think some more about what you're trying to solve for the problems your customers face, and see if you can get some help regarding the tech stack you should look to implement. If you desire SO to deliver these answers you'll need to ask them in a particular way, essentially having made a set of decisions yourself and be missing some facts that will drive the implementation choices - ask us for the missing facts rather than to make the implementation choices
If all the clients apps are on the same network and can see a central server, then there's no reason you can't use the Access database in the same way you would a SQL Server database, i.e. by placing it somewhere where it can be accessed by all copies of your application. Access isn't the last word in database features or security, but it's perfectly workable.
We normally create a mapped drive on the client PCs to a location on the server, so that everyone can use the same connection string for the database, e.g. T:\yourdatabase.mdb.
If the clients aren't on the same network and you can't use a VPN to connect them then to single network then things will become a lot more difficult, and moving to SQL Server will probably be a lot simpler.
Essentially, if this is an in-house system where the data isn't too sensitive and all the users are members of staff say, then a central Access database can work fine. If this is an app that's being used by people outside your organisation then SQL is a better choice if you want your app to talk directly to the database.
Alternatively you could write an API that you host on a web server, then your client apps can talk to the API and your API can talk to the Access database.
Ok I have searched and searched for an answer to my problem but can not find a direct answer.
Can someone please guide me in the direction I need to go with step by step solution somewhere that is useful?
My Question:
I built an Windows 8.1 Metro Application that needs to pull data and store data into a database I am hosting in MySQL online but I can not use things like My.SQL.Data.RT because it is not supported (I guess) because I get an error.
How do I connect to my online database to pull information from and store information to it? If I can not do this what options do I have?
Using local databases is not an option because everyone will be storing information in the database and pulling information from it from hundreds of different computers running the application.
If you could point me to a website that I can see it in step by step and please. I am using C#.
Thank you for your help. I have been racking my brain over this because the My.SQL.Data.RT works but the application fails to pass the Windows Store requirements with it pretty dumb if you ask me.
I'm not a Windows 8 store app developer so I am just trying to give suggestions.
From what I know, connecting directly to database server over internet from a client app is NOT A GOOD PRACTICE nowadays. Instead, people provide APIs to do it.
For example, Twitter provides restful APIs, so twitter clients can request http urls and get wanted data in JOSN format. The security of the the connection is ensured by oAuth (so that you don't transfer username and password in http request) and SSL/HTTPS.
In this way, the database connection is hidden from Internet. You will also benefit from the API layer if you want to develop another client on platforms other than Windows, e.g. iOS or Android.
By a quick google search, I found two guides about making a restful api with C#.
http://www.codeproject.com/Articles/112470/Developing-a-REST-Web-Service-using-C-A-walkthroug
http://www.asp.net/web-api/tutorials/hands-on-labs/build-restful-apis-with-aspnet-web-api
I am building a C# program for a company that eventually will store information about newspaper articles in a data structure. The key here is that they want to be able to query this data structure via a browser remotely, so the obvious choice I suppose therefore would be using something like SQL. So I have two questions:
If I use SQL how could I store results from the C# program as it runs to the SQL database? Would this involve opening up a connection inside the program akin to the mySQL command line console?
Is there an alternate way, i.e. where I could store the data inside the C# program solely that is running on the server, and query this for results via a web browser just as I would if I were using SQL?
Many thanks for your advice
you can communicate with an SQL server with C# ... It's pretty easy, lots of examples out there.
It would be better to use an SQL server. Using an internal database will mean you will have to implement a database mechanism that will be robust against crashes. SQL already is.
You can implement it easily by using ASP.Net (For accessing with a web browser).
Or look into WCF or web services if you want to implement your own browser. WCF or web services will give you tools to create a simple-to-use API that acts as a server.
I work on a Joomla web site, installed on a MySQL database and running on IIS7. It's all working fine.
I now need to add functionality that lets (Joomla-)registered users change some configuration data. Though I haven't done this yet, it looks straightforward enough to do with Joomla. The data is private so all external access will be done through HTTPS.
I also need an existing c# program, running on another machine, to read that configuration data. Sure enough, this data access needs to be as fast as possible. The data will be small (and filtered by query), but the latency should be kept to a minimum. A short-term, client-side cache (less than a minute, in case a user updates his configuration data) seems like a good idea.
I have done practically zero database/asp programming so far, so what's the best way of doing that last step? Should the c# program access the database 'directly' (using what? LINQ?) or setup some sort of Facade (SOAP?) service? If a service should be used, should it be done through Joomla or with ASP on IIS?
Thanks
I ended up using a WCF service façade written in c# that returns the data from the database. The service only exposes a couple of functions that query parameters as arguments. The SQL queries are not exposed, nor is the database connection string. The WCF service uses the mysql connector/net 6.3.1 to talk to mysql. The WCF service is accessible only over https, and requires a username & password.
I am designing a Windows application in C# which when run for the first time creates a local database (SQLite) and the data (around 200 MB or even more) to this is feed as a data stream from a remote server based on the criteria specified by the user.
Currently I have planned to access the database server directly from the application.
Questions:
Is it a good idea to use the database server directly from the application as the server manages connections automatically and I save time in developing a TCP/IP interface.
What can be the second option? Providing a TCP/IP server or interface (Isn't it time consuming to write it?).
As the data is large should I use compression?
With WCF you can avoid the cost of writing TCP/IP code and have a standalone server or a web service hosted on IIS. Moreover, compression can be added without code change.
You have to try with and without compression. The compression rate highly depends on the data and compression time can also be an issue.
Without going into large detail I can say you can use ASP.NET C# (You can choose any .NET language) and you can send and receive data using POST.
Why would you need compression? You are only sending results? If it is big you can use an existing library. I have used sevenzipsharp in the past without much issue.
Edit: There may be an option on the server to gzip output data so you may not need to use anything.
Assuming that your intention is to pull down a subset of the data on the server dependent on client queries for local storage then for reasons of security and control you probably ought to be looking at using web services rather than exposing your database directly to the internet.
There are a large number of options for creating services - WCF being the principal method for new .NET applications and straightforward to implement at both server and client ends - in this case I'd also probably take a look at ADO.NET Data Services as providing a shortcut to a rich set of services.
It is usually best to use ADO.NET or LINQ to SQL (Entity Framework) to connect to your Database directly unless the User is going to be disconnected while using the application.
If you are going to have the user disconnect then continue using SQLite or you can use ADO.NET which can save an XML file of the data and access it like a Table from the users machine without the additional dependence of SQLite.
I would not use compression because C# does not have a built-in library for it and would require an additional dependency.
Try to just use the .NET Framework without additional DLL's and you will have a more flexible application that is easier to install and maintain.
ADO/Entity Framework - http://msdn.microsoft.com/en-us/library/h43ks021.aspx