I need a webservice to get information of whole of the countries and their provinces location and area or population is anyone who knows this web service ?
why you need web service? I don't think so its exist.
what you need to do is, you can create table in your DB and add data, Its easy to find SQL insert queries to dump the data. please check these URLs
http://amrelgarhytech.blogspot.com/2008/08/list-of-countries-cities-languages.html
Country, state list for SQL Server
You can also use the great service from the chaps at http://www.geonames.org/
I did a small tool to generate an XML file based on the output of their webservices: https://github.com/yosoyadri/GeoNames-XML-Builder
All credit should really go to the C# library at http://geonamesdotorgdotnet.codeplex.com/ that I'm using to parse the response XML from the services.
You have an already made list of countries and provinces at https://raw.github.com/yosoyadri/GeoNames-XML-Builder/master/continents-countries-statesprovinces.xml
As Muhammad I think it is always good practice to keep your local copy of the data rather than querying the service everytime.
Related
I have a REST API that will be facilitating CRUD from multiple databases. These databases all represent the same data for different locations within the organization (IE We have 20 or so implementations of a software package and we want to read from all of the supporting databases via one API).
I was wondering what the "Best Practice" would be for facilitating what database to access resources from?
For example, right now in my request headers I have a custom "X-" header that would represent the database id. Unfortunately, this sort of thing feels a bit like a workaround.
I was thinking of a few other options:
I could bake the Database Id into the URI (/:db_id/resource/...)
I could modify the Accept Header like someone would with an API version
I could split up the API to be one service per database
Would one of the aforementioned options be considered "better" than the others, and if not what is considered the "best" option for this sort of architecture?
I am, at the moment, using ASP.NET Web API 2.
These databases all represent the same data for different locations within the organization
I think this is the key to your answer - you don't want to expose internal implementation details (like database IDs etc.) outside your API - what if you consolidate? or change your internal implementation one day?
However, this sentence reveals a distinction that is meaningful to the business - the location.
So - I'd make the location part of the URI:
/api/location/{locationId}/resource...
Then map the locationId internally to a database ID. LocationId could also be a name, or a code, or something unique that would be meaningful to the API client.
Then - if you later consolidate multiple locations to the same database or otherwise change your internal implementation, the clients don't have to change.
In addition, whoever is configuring the client applications, can do so thinking about something meaningful to the business - the location they are interested in.
Question
How can I access all contacts on a CommuniGate Pro Server?
Context
I need to migrate contacts from 70 email accounts stored on a Communigate Pro server. Since CommuniGate supports CardDAV, I decided to use this protocol rather than exporting the contacts manually from their web client, Pronto.
I have managed to access the CardDAV folders and to extract the vCards contained there. However, the problem is that not all of the contacts show up in CardDAV; in particular, the web client contains subgroups of contacts that are invisible in CardDAV.
When I export these subgroups from the web client, they are outputted as a txt file in a proprietary format called vCardGroup. Even though I wrote a PHP script to convert vCardGroup to vCard, using this method is still very slow.
I will be grateful if you suggest a way to extract these contact subgroups programmatically. I understand that CardDAV does not support subgroups, so I guess that the big question is: where are these txt files stored?
As a reference, please find here the result of a PROPFIND request on the root of the CardDAV folder. Note that CommuniGate seems to implement CardDAV via http://calendarserver.org.
Thank you for your attention!
After contacting the Communigate Pro (CGP) support team, I am able to answer my own question:
The only way to extract contacts programmatically from a Communigate Pro server is having root access to the server and use a protocol like XIMSS.
They also told me that CGP's support of CardDAV is limited, and does not include subgroups.
Since the server administrator is an evil man, I will have to extract the contacts manually using the web client, Pronto.
Just in case some poor soul is in my same situation, I provide a link to my script to convert the proprietary vGroupCard format (ie. BEGIN:VGROUP) to the standard vCard format (ie. BEGIN:VCARD).
I am planning to create sqlite table on my android app. The data comes from the the server via webservice.
I would like to know what is the best way to do this.
Should I transfer the data from the webservice in a sqlite db file and merge it or should i get all the data as a soap request and parse it in to table or should I use rest call.
The general size of the data is 2MB with 100 columns.
Please advise the best case where I can quickly get this data, with less load on the device.
My Workflow is:
Download a set of 20000 Addresses and save them to device sqlite database. This operation is only once, when you run the app for the first time or when you want to refresh the whole app data.
Update this record when ever there is a change in the server.
Now I can get this data either in JSON, XML or as pure SqLite File from the server . I want to know what is the fastest way to store this data in to Android Database.
I tried all the above methods and I found getting the database file from server and copying that data to the database is faster than getting the data in XML or JSON and parsing it. Please advise if I am right or wrong.
If you are planning to use sync adapters then you will need to implement a content provider (or atleast a stub) and an authenticator. Here is a good example that you can follow.
Also, you have not explained more about what is the use-case of such a web-service to decide what web-service architecture to suggest. But REST is a good style to write your services and using JSON over XML is advisable due to data format efficiency (or better yet give protocol-buffer a shot)
And yes, sync adapters are better to use as they already provide a great set of features that you will want to implement otherwise when written as a background service (e.g., periodic sync, auto sync, exponential backoff etc.)
To have less load on the device you can implement a sync-adapter backed by a content provider. You serialize/deserialize data when you upload/download data from server. When you need to persist data from the server you can use the bulkInsert() method in content-provider and persist all your data in a transaction
I am writing an ASP.NET web site where users will be able to upload a .CSV file from which i want to extract the data into a table on a MySQL Database. I was wondering what would be the safest way to do this by protecting against SQL injection or other dangers towards my database.
I was also wondering what would be the best way to extract this? For example would it be recommended to use an API to extract the data straight from the back of a button push or should I push the file to a temporary location where a service may pick it up periodically?
Thanks in advance
Use prepared statements to use your CSV data in the backend. Prepared statements securely escape data to prevent SQL injection.
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.prepare(v=vs.71).aspx
Never create a dynamic string that uses data by joining or concatenating strings. Only use the prepared statements.
This is universal and should be used regardless of the input source.
I have developed a CRM for my company. Next I would like to take that system and make it available for others to use in a hosted format. Very much like a salesforce.com. The question is what type of database structure would I use. I see two options:
Option 1. Each time a company signs up, I clone the master database for them.
The disadvantage of this is that I could end up with thousands of databases. Thats a lot of databases to backup every night. My CRM uses cron jobs for maintanance, those jobs would have to run on all databases.
Each time I upgrade the system with a new feature, and need to add a new column to the database, I will have to add that column to thousands of databases.
Option 2. Use only one database.
At the beginning of EVERY table add "CompanyID". In EVERY SQL statement add "and
companyid={companyid}".
The advantage of this method is the simplicity of only one database. Just one database to backup each night. Just one database to update when needed.
The disadvantage is what if I get 1000 companies signing up, and each wants to store data on 100,000 leads, that 100,000,000 rows in the lead table, which worries me.
Does anyone know how the online hosted CRMs like salesforce.com do this?
Thanks
Wouldn't you clone a table structure style to each new database id all sheets archived in master base indexed client clone is hash verified to access specific sheet run through a host machine at the front end of the master system. Then directing requests as primary role. Internal access is batched to read/write slave systems in groups. Obviously set raid configurations to copy real time and scheduled. Balance requests for load to speed of system resources. That way you separated the security flawed from ui and connection to the retention schema. it seems like simplified structures and reducing policy requests cut down request rss in the query processing. or Simply a man in the middle approach from inside out.
1) Splitting your data into smaller groups in a safe, unthinking way (such as one database per grouping) is almost always best if you want to scale. In this case, unless for some reason you want to query between companies, keeping them in separate databases is best.
2) If you are updating all of the databases by hand, you are doing something wrong if you want to scale. You'd want to automate the process.
3) Ultimately, salesforce.com uses this as the basis of their DB infrastructure:
http://blog.database.com/blog/2011/08/30/database-com-is-open-for-business/