Multi-user app

I am going to be making an application that will act as an appointment book.  Some questions I have are:

-  What would be the best data storage: text file, or database?

-  I am wondering how to handle the timing.  For example, how to make sure that each user has the latest data on their computer.

-  C++ or VB?  Which would be better?

-  Any other suggestions for a first timer?


This is the first time I have done a multi-user app that will be run over a network and I'm not sure where to start.

If you can offer any advantages/disadvantages of designs, your input is welcome.
matt_whiteAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

aleshCommented:
1. Most certainly database. It provides you a fast search option and alot of extra scalability which a text file does not and also most of the routines to write, search, etc., thru the text file you would have to write on your own.

2. Many ways: with the timer control, on user click, change of certain events. You have a large choice of options here. Something you shouldn't worry to much about.

3. Depends. How much time do you have on your hands? Really, really alot? I suggest VC, not so much time - VB, very little time - VB.

Perhaps a good suggestion would also be, read a book on programming with VB and databases.
Decide which techinque you will use to access the database before even starting the work.
Also note, that if this is going to be multiuser application you have to be aware of row-locking/page locking techniques and similar things (which all come down to writting an application with a database under.

If you have any other questions, regarding your original question, post a comment and I will try to answer.

I decided to provide this as a answer and not the comment, since I belive I answered all your questions. If you do not agree, please reject it.

Best wishes,
Alesh
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
mark2150Commented:
Database using memo fields works well for data storage.

Access is naturally a shared database. Keep one master copy of the schedule on the server and let each client query it. No special coding should be needed for this type of app.

VB is easier to get stuff running in and Access is native database for VB.

M
0
aleshCommented:
Mark2150:

Using memo fields is not so recommended technique. It eats alot of memory and disk space.
Access is not so nicely shared database. Record locking, etc. can give you a pretty big headache when it comes down to two users editing the same record, etc.
Access being the native database of VB? Err, where did you pick that up?

Alesh
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

matt_whiteAuthor Commented:
Thanks for the comments.

I have one final question.  Should I use a data control or ADO.  I'm not really sure what ADO is but I am thinking it is the alternative to the data control.  Which of these would be best, and if ADO is best, where could I find a good example to show me how to use it.
0
aleshCommented:
ADO stands for ActiveX Database Objects. It is based on DAO, but far more extended (OLE-DB support, native ODBC support, etc). ADO, DAO, RDO, etc... are ways of "connecting" your application with the database.
For example, DAO is limited mostly for use with Access databases, RDO was "made" to connect with ODBC databases (SQL server, Oracle, etc.), ADO, as I already said is based on DAO, but has what RDO has but again alot more (commands, paramaters (in-out)).

Data-controls are also divided. For example, like ADODC (ado-data-control), which is a data control with ADO, ordinary data control uses DAO (and limits you to only Access database, tho that is not entirely true, since you can connect DAO to Oracle for example).
Data controls are used for example when you want to have a grid with some results shown and you first have to use the data control to set all the properties to actually connect it do the database and then you BOUND the grid to the data control to display the records/results.
You can ask your self now, when to use data controls and when not? For easy-to-display results/records use data control. For sophisticated way of managing (inserting, updating, deleting) records don't use a data control, do it all thru code. Data controls are robust and are not recommended by 90% of the people and most of the books.
I hope I nailed down all the answers to your questions.


Best wishes,
Alesh
0
mark2150Commented:
Memo fields are appropriate when you have a sparse data set and no easy way to preallocate space. This app is an IDEAL canidate for memo's. Naturally you wouldn't use MEMO's for every field, but you can easily implement a memo field linked to a RichTextBox so you can have variable amounts of text, possibly containing font, alignment, and color changes. In a shared calendaring app some users will just set time and date while others will put in notes of the meeting. You don't want to have a fixed, say 2k, block assigned to a TEXT field when 90% of them won't have more than 10 bytes and the remaining 10% will want to be longer!

Generally for apps that are not highly transactional in nature the automatic locking of Access is sufficient. For a heavy inventory system, yes, you have to write special code. But for multiple users appending data or doing simple R/O lookups (as many users will *review* their schedules with writes being relatively infrequient) the normal operation should be find. For apps that have lots of users entering records I found that you can develop the App locally and just copy the .MDB to the LAN and everything will work *FINE*.

Access is "native" to VB in that VB's Jet engine will handle all of the file I/O and overhead that you would normally have had to do yourself with things like *text* files or fielded files.

M
0
vettrangerCommented:
"Using memo fields is not so recommended technique. It eats alot of memory and disk space."

Memo fields are variable length, and should be used anytime your data requirement calls for more than 255 characters. Excess worry about their demand on system resources in this day of massive hard drives and large system memory is silly.

"Access is not so nicely shared database. Record locking, etc. can give you a pretty big headache when it comes down to two users editing the same record, etc"

Gee, that's too bad. I guess I'll have to call all the clients of mine who have been running smoothly operating multi-user apps under Access for years and tell them they have to change. :-(

"Access being the native database of VB? Err, where did you pick that up?"

Hmmmn, could it be the fact that the default behavior of VB data controls is to connect to Access databases?

0
leesssCommented:
For fast development time, and not so portable db, use Data Control.

For slower development time and highly portable db use ADO code.
0
mark2150Commented:
Go Vett! :-)

BTW: I tend to avoid bound controls whereever possible. ADO is not particulary slower to develop one you know how. ADO may take (marginally) longer initially to code, but will save a huge amount of time in debugging as BOUND controls will sometimes (too often) do things unexpectedly.

M
0
leesssCommented:
mark2150,

You are right about the ADO coding time.  

Actually I say that coding ADO is slower because I assme one needs to create all the text boxes, combo/list boxes, labels to hold the db values, then he needs to code all the event handlers for the text boxes, combo boxes, then you need to create all the back/next/Update/delete/insert/cancel buttons and code behind them.

If one uses the wizard to create all the stuff, then it is a 5-10 minutes job (possibly faster).
0
vettrangerCommented:
Bear in mind that the Data Form Wizard, tho fast, creates buggy code. ;-)
0
matt_whiteAuthor Commented:
Great ideas!  I am a little more concerned now about one issue.

What if two users have the same record up at the same time, and they try to update it?  How does Access handle this?  How can I stop this from happening?  You have said that it would take *special coding*, but would I have to specifically lock the record (if so, how) or could I just change a field on that record when one person opens it to show that is currently opened and should not be messed with by anyone else?

Also, if anyone could point me to some examples for how to use ADO, that would be great!
0
mark2150Commented:
You can throw a lock on a 2k block with access if you need. But given the description of this app I'd just go ahead and code it straight and see how it behaves. If it's a "once a month" issue, then it's not worth writing code for it. I have a sneaking suspicion based on past experiences with calendaring apps that you should be ok with async updates.

Keep your read/modify/write's short and to the point. Don't fire a RS.Edit on FORM_LOAD and RS.Update on FORM_QUERY_UNLOAD. Have the update run in response to a button that only enables once you've validated your input fields.

M
0
matt_whiteAuthor Commented:
This will be accessed by approx. 15-20 people and will be accessed all thru the day.  The possibility of two people accessing the same appointment time IS possible.  Not all that likely, but possible.
0
mark2150Commented:
If its not that likely, then chances are that Access's native sequencing will be fine. Give it a shot and if you have lots of contention, go back into the critical sections and throw a lock around the updates. No biggie, certainly no reason to hold up project at this stage.

M
0
amit_panjwaniCommented:
Why DOnt u Try SQL Server 7.x as Backend RDBMS and VB as Front End.

Will Appointments of one user effect another user's Appointment, or u r going to syncronize these thing Programmatically.

What part of appointments will be visible to Other Users.

and Besides That Try going through

Roger Jennings Database Guide it is one of best books on Database Developments.
0
mark2150Commented:
Amit,

Jeeze do you really think that a 15-20 user app needs the expense and overhead of building a client server model?

Access on a LAN will work *fine* in this context without any ODBC drivers, an SQL server or anything else that your solution implies.

Principle of KISS applies here. Access is well suited to this, a SQL server would be overkill.

M
0
amit_panjwaniCommented:
well if they could use a ppointment sort of program on lan and would use it round the day,
secondly the scalablility it is going to offer, with 15-20 people, i dont  think it is going to KISS sort of application.

Moreover i dont say that he has to go deep in to DB administration.


If it were that KISS ,  he could have used foxpro for windows 2.6 as well.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.