• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Database question

Emret

Limp Gawd
Joined
Feb 18, 2004
Messages
342
I could use some advice on how to do the following tasks, i know it has something to do with databases etc but im not very informed on the subject..any help i would appreciate very much..

- I need to prepare different forms with 70-100 questions, some with true/false values, some with numerical values, comments boxes or multiple selections etc. with ability to upload pictures.

- the staff will login, choose a form and fill it out on the go by mobile devices such as blackberries, ipads or laptops, pictures will be uploaded along with the forms.

- values from the forms will be analyzed, edited at the office to create final reports.

What program(s) would i need to do this as easy as possible?
 
Last edited:
You're talking about creating a SCORM system, with further enhancements to GUI based on device (computer versus smartphone). Based on your first paragraph, I'd strongly advise against trying to roll your own; instead, find a SCORM-capable development partner.
 
you can make a simple website using php and mysql on any cheapo $10/month host.

then just extract the data into Microsoft excel or access to run your reports.
 
please don't use the term "real-time" in contexts like these.

Unless you are developing a control system for a fighter aircraft or a surgical laser or something like that, then you don't want real-time, you just want fast.

Thank you.
nbc_the_more_you_know1-300x197.jpg
 
It doesnt have to be a sophisticated system, let alone expensive :) which SCORM seems to be.

I have very little php and mysql knowledge, where would I need to start?
also would it be easier to do with MS Access ?

and ok, scratch REALTIME :)
 
It doesnt have to be a sophisticated system, let alone expensive which SCORM seems to be.
SCORM is a list of guidelines, not a single system. Guidelines which are a good fit for the requirements (and implied scope) you've already listed.

I have very little php and mysql knowledge, where would I need to start?
also would it be easier to do with MS Access ?
It more sounds like whatever technology you choose will also be a first introduction. One alternate approach would be looking at a CMS or Sharepoint site, and looking at "test"-style addons for them.

Another question to ask on whether to roll your own solution is if you have enough time to learn multiple technologies, design a data schema, architect the common capabilities, and develop a solution. If you're not against a calendar wall, then take a stab at it. Otherwise, start looking into system that align with whatever technology path that you and/or your company is on.
 
Unless you are developing a control system for a fighter aircraft or a surgical laser or something like that, then you don't want real-time, you just want fast.
Not exactly. "Real time" is "fast enough". Really, it just means that the work required can be completed before more work arrives. That's a requirement often found in both flight control and web-based systems.
 
Not exactly. "Real time" is "fast enough". Really, it just means that the work required can be completed before more work arrives. That's a requirement often found in both flight control and web-based systems.

It sounds like what the OP is wanting is a reasonably responsive, mostly up-to-date system. He doesn't care if the guy at the office can't pull the report up within 5ms of the time it's stored. He doesn't care if it takes 2 seconds to transmit and store the report. He just cares that everyone is working off of the same database and not local copies until a later sync time or some such. If he has a network hangup and a report submittal is delayed for a minute or two, no data is loss, there's no real impact. That's not really real time.

In my world, and to most anyone that works in my world real time means that work can be done on a schedule within expected bounds of accuracy and/or performed within a guaranteed amount of time.

If you need to maintain a 1hz hardware signal, firing it off 60 times in under a second and then waiting 60 seconds to fire again isn't going to work. You need to send that signal at 1hz +- some acceptable bounds of error. And likely will have an acceptable range of creep and synchronization methods to ensure that what creep does occur is corrected for. (i.e., 975ms delay each time will creep too much, 975 then 1020 then 1010 then 995 won't)

Likewise, just getting work done before more arrives isn't enough. You may have requirements such as a need to have a packet of sensor data received, processed and to the consumer (algorithms, control vane actuators, or whatever) in under 5ms even though the sensor is only sending data at 10 hz. The data is worthless or worse than worthless if it arrives at the end consumer too late.
 
In my world, and to most anyone that works in my world real time means that work can be done on a schedule within expected bounds of accuracy and/or performed within a guaranteed amount of time.
Yep, that's a common definition. The only difference between this requirement and the requirements you've established for the OP's web system is the definition of "fast enough"

If you need to maintain a 1hz hardware signal, firing it off 60 times in under a second and then waiting 60 seconds to fire again isn't going to work.
The way I'd describe it is synchronous, or synchronized, or low-jitter. Thing is, sending 60 pulses in less than a second isn't 1 Hz in the first place.
 
Yep, that's a common definition. The only difference between this requirement and the requirements you've established for the OP's web system is the definition of "fast enough"

It's also related to what happens when you don't meet your requirement of "fast enough". In the OPs case, if he says 2 minutes to sync a submital with a retrieved item, if it takes 121 seconds there's no loss of data, there's no accuracy loss, etc. The timing is non-critical.

The way I'd describe it is synchronous, or synchronized, or low-jitter. Thing is, sending 60 pulses in less than a second isn't 1 Hz in the first place.

Yes, my example was silly, but it serves to illustrate a point. 60 pulses in under a second each and every minute could be treated as 1hz by a non real-time system (as in, you got your 60 pulses each minute, what's the problem?)
 
In the OPs case, if he says 2 minutes to sync a submital with a retrieved item, if it takes 121 seconds there's no loss of data, there's no accuracy loss, etc. The timing is non-critical.
Maybe, or maybe not. You're still using your presumed requirements. At this point, there's the system you're designing and the system the OP is talking about. Would discussing either bring us closer to agreeing upon a definition of "real time"?

Yes, my example was silly, but it serves to illustrate a point.
Not at all -- it was too absurd to make any sense of and as such didn't demonstrate any salient point about the definition we're investigating. Your intent appears to be to define something that counts 60 pulses per minute when 1 pulse per second was intended as not real-time, but it might also be real time if the pulses are really at 1 second intervals. You're using convenient round numbers, but forgetting that tolerance and inaccuracy exists no mater how deeply you look. Would you similarly discard a system that sends pulses at 1.001 hertz, 0.9999999 hertz, or 1.0000000001 hertz as "non real time"?

The fact is that my definition stands; once you decide how accurate or how fast really matters, you don't have to worry about it anymore. Usually, but not always, that's at the point where no other work could have (or needed to) happen anyway.
 
Back
Top