Database/Server selection

[KevanC]

Hello... I've been using Dreamweaver for several years. I'm pretty good doing plain HTML pages. However, I'm a novice with data-driven sites. I'm trying to choose a database and server to support a project that I've been tasked with at work.

We have MDTs (Mobile Data Terminal) in our fire apparatus. They are basically mobile PCs with a touchscreen. They have no internet connectivity. They run Windows XP Pro. I am working on a site that I can load all of our preplans (building layouts) onto. Responders would be able to copy and paste an address or business name into a search field to pull up information quickly. Eventually, I'd like to add a field that allows comments to be input on each field.

I've already designed a simple HTML page that points users to a directory that contains all the images of the preplans. I'd like to pair the pictures up in a database to allow more identifying features for search.

The problem is, there is no extra software loaded onto the MDTs. I can do what I need to get the program working. But, I'm looking for the least invasive way of setting up something on each MDT. The site will always run from the local host. And, I prefer the web design for ease of use. Most people know how to point and click. Does anyone have any suggestions or recommendations? I've used Microsoft Access. But, I wasn't sure if there were any smaller or easier solutions. I'm also lost on which server to use (PHP, ASP, CF, etc). Any recommendations would be appreciated.

[Stephen Philbin]

PHP, ASP and CF are server side languages, but they are not servers themselves. The two most common http servers are Apache (comes with just about every Linux distro ever produced and is native to Unix/Linux) and Microsoft IIS (comes with XP Pro and is native to Windows). The native server side language to Apache is PHP and the native server side language to IIS is ASP (Though if you're using Windows you're supposed to be going with that .Net business these days).

Just because all those portable things are Windows though, doesn't mean the server they'll connect to has to be too though. You can go with whatever is cheapest or easiest or best or whatever for your needs. Though if the computer you intend all the others to be served by is already Windows based, then I think your best choice is almost certainly going to be IIS. You can just switch it on by some option in some tab somewhere. One of the guys will drop by and let you know where the option is soon. ;)

Oh and you'll probably wanna go with a Win based database like access too, if you're using IIS and asp.Net

[NogDog]

Not sure if it's clear from Stephen's post, but Apache and PHP can be installed on Windows.

[Stephen Philbin]

Yeah. Sorry. By "native", I mean that they naturally run on that system. It's the system they were originally built for, but you can still install and use them on non native platforms. They just tend to lose some of their more in depth and fine detail abilities. It's rare that any setup that doesn't need to squeeze every last bit of juice out of every single cpu cycle would have any serious issues though.

[KevanC]

Thanks... I'd like to stick with what's native to the computers and introduce as little 'new' to the system as possible. So, I should stick with IIS and ASP.NET. To get this right, I will just need to activate IIS (I've done that before) and develop my pages in dreamweaver using ASP.NET. I can copy the web onto each computer along with the .mdb and everything should work fine... correct? If so, that sounds to be the least invasive.

My reason for keeping it so basic and simple is because the main use of the MDT is for communication. We acknowlege calls, mark on the scene, and return to service with the computer. I don't want to clutter it with a bunch of stuff. Plus, it will have to be something easily deployable through a fleet of 25-30 apparatus.

Thanks for the info. Feel free to correct me if I'm wrong on any of those assumptions.

[Stephen Philbin]

Well I was thinking more aling the lines of a centralised "Intranet". Have a single computer with IIS activated and install on that computer the single database and the ASP language or the .Net framework or however it goes with the Windows stuff. Then to develop your .Net application that will run on that single computer I think you're supposed to use Microsoft Vistual Studio. Once you have your server with the database, the application to process the data, and of course the language that the application will run in (asp.Net I assume), then you just have your other portable computers connect to it via their web browsers.

The idea being that all your data is at a centralised location, you can manage all your data in one place and won't end up with miss-matching data sets, you can manage your application at a single point (rather than having to maintain each and every installation of the application) and all your other portable devices will already have the required software (like a web browser) ready installed on them and will require no further specialist software or maintainance.

[KevanC]

Unfortunately, each MDT is seperate. There is no connectivity between them. I'll have to set it up on each individual computer. They are all mobile in fire trucks and ambulances. The way they work for communication is a short burst text message over a radio signal. It's less than 10K. It would have to be setup on each individual computer to run independantly. It's a tough nut to crack. I'm not sure how feasible it's going to be at this point. But, I'm going to give it a try on one machine to see how it will work.

[Stephen Philbin]

Does all the data in the databaseses need to be synch'd too? Like if one station adds data into a database, would it need to be immediately available to all others? If so I really wouldn't go this way. If I had a boss that told me to keep 30+ individual databases synch'd, I'd tell him he's crazy and quit. I think you're going to need something other than regular web tech.

[KevanC]

Yes and no... there are new preplans to add from time to time. But, the comments field can remain seperate. I know that isn't going to work. So, I'm going to give it a try without any input fields. Then, I would just need to copy the updated mdb file monthly, or so.