I suggest you get someone to help with your english first. The question needs some interpreting.
The forum does not supply service so the someone is not going to happen.
Converting between databases will depend on the vendor of the database so know which source and target database is going to help us help you. http://www.sqlservercentral.com/[^] is another good resource for SQL Server and all the big vendors have similar support sites.
Never underestimate the power of human stupidity
I'm looking for a database where I can directly send / receive TCP/IP commands to do manipulate the database with SQL commands. I doubt that there is anything like that out there since my Google searches didn't turn anything up, but I'm asking here in case I'm missing something...
I will never again mention that Dalek Dave was the poster of the One Millionth Lounge Post, nor that it was complete drivel.
I was thinking about something that needs a previous authentication, and then SQL commands can be sent...
Which is how every database that uses SQL works.
The MS SQL Server Management Studio manages the server which is not and cannot be the same as managing a database. Same is true of tools like sqlplus, Toad, MySQL Workbench, etc. One can use those to process SQL but other functionality cannot be controlled via SQL (because that isn't what SQL does.)
we r developing visitor tracking system,when avisitor come giving a card and he swips and enters inside ,when he releaving handovers the card to watchmen.after that there is a chance same card can be given to someother visitor.
mysql table is not having primary key.
table is like this:
On the last project I was on, we utilized MS Access and while I was for the most part able to get around in Access, I found Access performed very, very slowly for even simple tasks once the DB grew to a certain size, and I was not at all impressed with the Report builder as I found it was almost always easier to export the data to Excel to generate my reports.
Fast forward a few months and I am about to start a new project and I have been given quite a bit of say in how we set up our database. I do have a vague idea of how I would implement it but I am very curious to see others opinions as well to make sure I have all bases covered.
Here are the 'contraints' if you will for how the database will need to perform.
1. There will be a few technologically savvy employees (approx 4-5) on site and the remainder of the workforce will be fairly illiterate, technologically speaking (they will be able to surf the web, do data entry in spreadsheets, type documents, but not much else). All employees will need to be able to access the data from reports easily and quickly without having to memorize commands or know how to navigate a database etc. My fellow techies have experience mostly with MS Access, and a couple know SQL, I am more familiar with NoSQL type frameworks, but have a basic understanding of SQL and can get by in such a system.
2. Data will come from 4 sources.
a.) Primarily, most data will come via spreadsheets. These spreadsheets will often be fairly complex with multiple tables, hidden columns and rows, formulas, reference cells, etc.
b.) The next largest chunk of data will come from field reports hand written by the foreman on site.
c.) The next largest chunk will come from simple verbal communication, or emails, word documents, or even typed letters.
3. Data will need to auto-generate reports. The more autonomous this can be made, the better. We might have as many as 10 different daily reports as well as hundreds of weekly, monthly, and yearly reports that we will have to generate. Ideally, this could be performed by non-techie users simply by providing date ranges or other simple constraints, and having templates scoop the required data from the database.
4. Data will need to be backed up often (at least once maybe more per day, to prevent data loss or erroneous operations, and preferably will not interfere with it's usage at all. It needs to scale well, be reliable and not be subject to data loss, or easily let data fall between the cracks.
In terms of importance I believe it should be arranged in the following hierarchy-
1. Reliability (no data loss, works as expected, no crashes, bugs, or unexplainable quirks)
2. Ease of Use (both in terms of non-techies accessing the data and power users overseeing the data and building report templates)
3. Performance (scales well, doesn't take minutes to perform simple queries)
In my head I see a few potential ways of allowing this to happen but invariably I see potential pitfalls in any of my strategies. I would be thrilled to see a high-level concept of how someone with more DB experience than myself would tackle this situation.
1. All employees will need to be able to access the
data from reports easily and quickly without having to memorize commands
That means you need a UI. That probably means you'd need to write one, generate one, or use Access as your front-end.
2. Data will come from 4 sources.
The database doesn't care where the data comes from. A is a simple import-operation. B and C cannot be automated, someone will have to enter the data. D is missing.
3. Data will need to auto-generate reports.
Data doesn't do things, it just sits there. Databases are also usually not responsible for generating a report; you will probably need to create a report-template that gets filled dynamically, with a filter for each property. I'd put the database in SQL Server, link from Access to it, and exclaim it's "done". Access has a low learning-curve and everyone could click together the reports as they see fit. Excell could probably do the same.
4. Data will need to be backed up often (at least once maybe more per day, to prevent data loss or erroneous operations
Backups do not prevent errors; any error gets backed up along with the rest of the data. Any major database-server supports backup-operations.
In terms of importance I believe it should be arranged in the following hierarchy
It doesn't work that way. There's a comparison of database-servers here[^] - take a look at the capabilities, compare them to your needs, pick one. And make sure it is SQL Server that you pick. SQL Server Express is free, you could design your db in Access (and have a working Access-db as a backup if this experiment fails), and simply import it in SQL Server when you're ready (using the upsize-wizard in Access)
"No bugs" is something that can never be guaranteed in complex systems; there's however a difference in patch-frequency. I know most people disable their auto-update, but I kinda like being updated regularly.
You can also safely assume that databases store data without loss, unless it's beta-software. And yes, all major database-servers return data on simple queries in nearly no time.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]