Intranet Design

[peterbata]

Hello all. First time post. A little background before I ask my very first NEWBIE question.

Have committed myself to the design of a business software solution for an existing client. For approx 10 years, they have been using a custom MS Access database to keep track of their magazine subscribers. The fellow who designed the app moved on to a cushy governmental job, and has basically left my client with no one to support his work.

To make an already long story short, I have been mandated to deliver a spanking new solution. I thought that the fit was right, as I have been maintaining their IT infrastructure for the longest time.

The database will be accessed by a total of five employees. Three of whom will be strictly reading information that the remaining two employees will be entering. Web access from the web is not required.

Hence my foray into PHP, MySQL, HTML. Have I made the right choice?

I realize that this question is somewhat pre-mature. Seeing as HTML will be used to display much of the content, and that a browser will be used to do so, can I strip the browser of all menus, status and toolbars. Thank you all in advance, and my apologies for the long-winded post.

[smantscheff]

If you have a good working knowledge of MS-Access and its ways there is no need to migrate the application to MySQL.
But if you are determined to migrate, MySQL is a good choice - very performant, good functionality.
Yes, you can strip the browser to a bare window. But why?
Have a look into HeidiSQL, Navicat and phpMyAdmin which might save you tons of work. In many cases it's easier to give the (few) backend users a thorough training than to set up an application which only performs standard operations (insert, update, delete).

[peterbata]

Thanks so much for the prompt reply.

MS-Access is completely foreign to me. I will however be faced with the task of importing all existing data (somewhere in the neighborhood of 17,000 records) into the newly created MySQL tables.

As far as the browser goes, I don't think that I really want them to stray away from the application. As I said earlier. When they work in Access, that's it, no surfing. They rely on IE for the browsing. Why change it up?? That is what they have become accustomed to.

Have had some exposure to phpMyAdmin. Thanks to Wamp and a book I purchased: PHP and MySQL Web Development - Fourth Edition by Luke Welling and Laura Thomson.

A good read, but the learning can get a little daunting at times. Have also fiddled around with Navicat a little bit.

I dedicate everyday of the week to learning as much as I can through reading or video tutorial. I have up to eight months to complete the project so I try not to panic too much. It's like going back to school and sitting in a classroom for 6 to 8 hours a day. Except I have been out of school for almost 30 years. There are some things in the book that I have trouble wrapping my head around, or just retaining. I suppose if I go over it enough times something is bound to stick. Thanks again. Have a safe and wonderful weekend! Peter

If you have a good working knowledge of MS-Access and its ways there is no need to migrate the application to MySQL.
But if you are determined to migrate, MySQL is a good choice - very performant, good functionality.
Yes, you can strip the browser to a bare window. But why?
Have a look into HeidiSQL, Navicat and phpMyAdmin which might save you tons of work. In many cases it's easier to give the (few) backend users a thorough training than to set up an application which only performs standard operations (insert, update, delete).

Hi Peter,

If you want to strip the browser of all the toolbars, have a look at Prism.
http://prism.mozillalabs.com/
It was developed by Mozilla Labs and basically turns a webpage into a stand alone application. I use it for a few local and web based applications and it is very easy to set up.

Good luck with your project and if you need any help along the way, DaniWeb is here to help.

[peterbata]

Thank you. I appreciate it very much. I will take a look at Prism tomorrow morning. Actually, it's already morning here!

Again, thanks for your time and assistance. Have a wonderful day. Peter

Hi Peter,

If you want to strip the browser of all the toolbars, have a look at Prism.
http://prism.mozillalabs.com/
It was developed by Mozilla Labs and basically turns a webpage into a stand alone application. I use it for a few local and web based applications and it is very easy to set up.

Good luck with your project and if you need any help along the way, DaniWeb is here to help.

[pixelsoul]

This question has many correct answers. More questions would need to be asked to really give the best possible answer.

If you are trying to build something from the ground up from scratch and want it to run in the browser than MySQL, PHP would be good a choice. But it sounds like you want to keep them from using a browser to access the data in the database?

My thought process also includes growth, needed features, and other possible changes going down the road to determine what path I would take. I agree completely with smantscheff that if you are trying to just move it to a MySQL database but want to keep from using a browser to access the data you might as well use a SQL database browser like mentioned.

[peterbata]

Good day, and thank you so much for your input.

I have no issues with having the user(s) accessing the data via a browser. I would prefer that they not use said browser for anything else but. So, running IE for their surfing pleasure, and let's say Firefox to access their membership app would suit me just fine.

As far as growth is concerned. Aside from the mundane task of entering new subscribers to their magazine, and having their small in-house sales team accessing that info, it is very doubtful that the app would see much in the way of expansion. Although added features could be requested at some point in the future.

This question has many correct answers. More questions would need to be asked to really give the best possible answer.

If you are trying to build something from the ground up from scratch and want it to run in the browser than MySQL, PHP would be good a choice. But it sounds like you want to keep them from using a browser to access the data in the database?

My thought process also includes growth, needed features, and other possible changes going down the road to determine what path I would take. I agree completely with smantscheff that if you are trying to just move it to a MySQL database but want to keep from using a browser to access the data you might as well use a SQL database browser like mentioned.

Be aware of security. Will you be hosting this 'app' on a remote server (e.g. website) or a local one (e.g. on your work's network)?

Having said that, you could have a remote DB and an interface on your local server.

If local server, will the pages be available to the outside world?

Transferring data between Access and MySQL is reasonably straightforward (http://www.kitebird.com/articles/access-migrate.html).

What's not so straightforward is duplicating the forms and reports that Access produces. THat may take a heck of a long time, depending on the complexity of the app. Queries will have to be reformatted too as Access SQL isn't quite the same as MySQL SQL, although you may find that they work OK for what you have.

Finally, do you really have to go down this route? Would not a study of the access DB system be easier? You could upgrade to MS 2010 and fiddle with it? It may be worth considering.

[peterbata]

YES, the data will be hosted on a local machine and NO the data will not be accessed from outside of the premises. However, I plan on backing everything up to a remote location. My office.

I plan on taking an inventory of all the reports that they require, and doing my best to duplicate them. Actually, from what I have seen so far, they generate reports on a quarterly basis, and they number approx 12-15 in all.

Some time before taking on the project I gave your last point about going the Access route a great deal of thought. To be honest with you, I had originally started working with Filemaker Pro months before signing on to the project.

Be aware of security. Will you be hosting this 'app' on a remote server (e.g. website) or a local one (e.g. on your work's network)?

Having said that, you could have a remote DB and an interface on your local server.

If local server, will the pages be available to the outside world?

Transferring data between Access and MySQL is reasonably straightforward (http://www.kitebird.com/articles/access-migrate.html).

What's not so straightforward is duplicating the forms and reports that Access produces. THat may take a heck of a long time, depending on the complexity of the app. Queries will have to be reformatted too as Access SQL isn't quite the same as MySQL SQL, although you may find that they work OK for what you have.

Finally, do you really have to go down this route? Would not a study of the access DB system be easier? You could upgrade to MS 2010 and fiddle with it? It may be worth considering.

Here is my reasoning behind why I chose PHP, MySQL, and HTML. In the event that I am no longer able to support / maintain the database and the programming that goes along with it. Seeing as how the PHP & MySQL community is so vast, and open source, I assumed that they / I would have an easier time finding someone to replace me. As opposed to finding someone to take over a Filemaker or Access suite. I could be wrong, but I hope not!

Thanks again for your input. I am keeping track of all the help that I have received from the fine folks here on this forum. Peter

> Here is my reasoning behind why I chose PHP, MySQL, and HTML. In the event that I am no longer able to support / maintain the database and the programming that goes along with it.

Very noble. Could I suggest that you document your code thoroughly. Perhaps that goes without saying.

good luck.

[peterbata]

I most definitely will. The eventual transition, if there should ever be one, should be made as painless as possible. Plus, I am not getting any younger.;)

BTW. Took a few minutes to check out the various data import / converters. They look quite promising. One day at a time though. Still a ways from that process. Have yourself a wonderful day / evening. Peter

> Here is my reasoning behind why I chose PHP, MySQL, and HTML. In the event that I am no longer able to support / maintain the database and the programming that goes along with it.

Very noble. Could I suggest that you document your code thoroughly. Perhaps that goes without saying.

good luck.