Click here to Skip to main content
15,887,683 members
Home / Discussions / Database
   

Database

 
AnswerRe: getting last inserted row Pin
Peter Leow10-Apr-14 22:18
professionalPeter Leow10-Apr-14 22:18 
GeneralRe: getting last inserted row Pin
Member 1026351910-Apr-14 23:01
Member 1026351910-Apr-14 23:01 
GeneralRe: getting last inserted row Pin
Mycroft Holmes11-Apr-14 2:30
professionalMycroft Holmes11-Apr-14 2:30 
AnswerRe: getting last inserted row Pin
Bernhard Hiller10-Apr-14 23:17
Bernhard Hiller10-Apr-14 23:17 
QuestionDatabase Planning Pin
Sea_Sharp10-Apr-14 6:03
Sea_Sharp10-Apr-14 6:03 
AnswerRe: Database Planning Pin
Eddy Vluggen10-Apr-14 7:17
professionalEddy Vluggen10-Apr-14 7:17 
GeneralRe: Database Planning Pin
Jörgen Andersson10-Apr-14 7:36
professionalJörgen Andersson10-Apr-14 7:36 
GeneralRe: Database Planning Pin
Sea_Sharp10-Apr-14 9:06
Sea_Sharp10-Apr-14 9:06 
Eddy Vluggen: That means you need a UI. That probably means you'd need to write one, generate one, or use Access as your front-end.

My thoughts were to restrict non-techie access completely from the database. They can enter data via spreadsheets which we would subsequently import. And to get data they can simply use the spreadsheets or pdfs that the reporting would generate. I found on the last project, having many people access the database at once resulted in many issues.


Eddy Vluggen: 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.

I actually merged D with C and forgot to change it to 3 sources after the edit. Agreed that the database doesn't care how it gets it's info. This was I suppose an extension to the previous point that if we hire people to do data entry, it would probably be best in my opinion to have those workers enter the data into spreadsheets that would be imported to the database rather than having them enter the data straight into it with forms. The less people clicking around in the db not knowing exactly what they are doing, the better IMO.


Eddy Vluggen: 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.

I guess my wording here was awkward. I know that data itself cannot do things. I meant that I would like to set up some process by which we can generate report blanks, and pull the data from the database to auto-populate the reports. I know Excel can do it via exports but then it becomes the issue of everyone wasting their time trying to make the reports look professional, consistent, and legible, not the end of the world mind you but it gets old quick when you have to generate reports continuously. As mentioned earlier I was completely unimpressed with the UI for Access's report builder but looking around I have not seen any alternatives that seem any better. My mindset is based more around the NoSQL movement so I would simply write a script to scrape the data off a document database and generate the report via HTML & CSS or XML & XSLT, but I am not sure how one might do that efficiently with an SQL database especially considering how complex joins can end up being, nor how flexible some frameworks would be about this.


Eddy Vluggen: Backups do not prevent errors; any error gets backed up along with the rest of the data. Any major database-server supports backup-operations.

Once again I agree with you, backups do not prevent errors, however they do provide a point of return if something bad does happen. Losing even a couple days worth of data entry due to a corrupted database file would not fly with our executives. Especially if connections to the database occur over a network, I find them to be very finicky and prone to small bugs. You should have seen how bad our MS Access db got corrupted just by having 2-3 people working on it simultaneously. Typos are bound to happen, very difficult to prevent them all. But if we have several snapshots of the database at any given point and an issue occurs we can restore to the most recent point that does not contain the errors and continue.


Eddy Vluggen: 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)

I think in terms of frameworks, there is always a little give and take between performance, stability, and ease of access. Ideally they would not conflict, but the world is far from ideal and resources are finite. There will always be a point where the effort you have to put in greatly exceeds the value you get out. In that sense, I put the hierarchy as a way of saying if one thing HAD to be sacrificed I would say speed and or usability over stability. What good is speed or usability if the framework hiccups over network connections and loses input or corrupts files without error warnings.


Thanks for your responses. I think in a lot of ways you were actually agreeing with my mindset on how to proceed. I still am very undecided on the reporting process, but I hope to have that worked out soon. Access could be used in a pinch, but as I mentioned earlier I think it would make a lot more sense to do it HTML and CSS or XML and XSLT for professional looking reports to the client, and unformatted spreadsheets for internal usage. Any advice on how I might implement that would be greatly appreciated.
AnswerRe: Database Planning Pin
Eddy Vluggen11-Apr-14 9:09
professionalEddy Vluggen11-Apr-14 9:09 
SuggestionRe: Database Planning Pin
Kornfeld Eliyahu Peter10-Apr-14 7:45
professionalKornfeld Eliyahu Peter10-Apr-14 7:45 
AnswerRe: Database Planning Pin
Mycroft Holmes10-Apr-14 13:05
professionalMycroft Holmes10-Apr-14 13:05 
QuestionMySQL Create every Sun for date = xx Pin
Jassim Rahma9-Apr-14 1:46
Jassim Rahma9-Apr-14 1:46 
AnswerRe: MySQL Create every Sun for date = xx Pin
Eddy Vluggen9-Apr-14 3:00
professionalEddy Vluggen9-Apr-14 3:00 
GeneralRe: MySQL Create every Sun for date = xx Pin
Jassim Rahma10-Apr-14 1:09
Jassim Rahma10-Apr-14 1:09 
AnswerRe: MySQL Create every Sun for date = xx Pin
Mycroft Holmes9-Apr-14 13:01
professionalMycroft Holmes9-Apr-14 13:01 
Questioncan I trust Triggers? Pin
Jassim Rahma9-Apr-14 1:04
Jassim Rahma9-Apr-14 1:04 
AnswerRe: can I trust Triggers? Pin
thatraja9-Apr-14 2:16
professionalthatraja9-Apr-14 2:16 
GeneralRe: can I trust Triggers? Pin
Bernhard Hiller9-Apr-14 22:23
Bernhard Hiller9-Apr-14 22:23 
GeneralRe: can I trust Triggers? Pin
thatraja10-Apr-14 21:06
professionalthatraja10-Apr-14 21:06 
QuestionRe: can I trust Triggers? Pin
Eddy Vluggen9-Apr-14 3:00
professionalEddy Vluggen9-Apr-14 3:00 
AnswerRe: can I trust Triggers? Pin
jschell10-Apr-14 8:53
jschell10-Apr-14 8:53 
GeneralRe: can I trust Triggers? Pin
Jassim Rahma12-Apr-14 1:36
Jassim Rahma12-Apr-14 1:36 
QuestionTrigger on select Pin
Jassim Rahma9-Apr-14 1:00
Jassim Rahma9-Apr-14 1:00 
AnswerRe: Trigger on select Pin
thatraja9-Apr-14 2:13
professionalthatraja9-Apr-14 2:13 
AnswerRe: Trigger on select Pin
Eddy Vluggen9-Apr-14 3:00
professionalEddy Vluggen9-Apr-14 3:00 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.