Chris, SQL Server, or any other RDMS is not a magical pill that when you drop them into your project Database problems solve themselves.
If a server based RDMS is going to be used, you are going to have to write your program with a 'central store' in mind. This means that you will not have the 30 users creating multiple files. They will all be working in the same instance of the SQL Server and they may all be editing the same file, or even the same table in the file. This mean's, that in your coding you have to consider concurrency issues where in the past using access and local field, concurrency was almost impossible. Secondly, using a central store, you will need to be more careful with the your use of data controls and the size of recordsets, as all data requests will be transferred over the network. It is easy to flood the network, particularly if it is busy to start with, to the point of unreliability. Regularly requesting entire tables for example will really bog down the network. It is also a good time to examine the ability of the server you are intending to use to service requests from 30 users. It is no good if you build really great software, if the server just can't deliver to the users. There is a reason that most people that have database applicatations on a server, also have a dedicated server for the database. For this sort of development you really need to look at existing infrastructure to make sure that it will be able to deliver. Several 'rules' are; keep recordsets as small as you possibly can limit refreshing the data in recordsets unless it really must be refreshed. Use stored procedures on the server as much as possible. This optimises performance Don't assume that user machines have any software on them. Be prepared for implementation problems. i.e. install and test run your software for a week or two before a complete change over occurs. If possible switch a few uses at a time to capacity test. I have often seen software developed and tested as Ok, fall in a heap on the first day 'live' due to capacity problems. I used to work for an organisation that implemented a major mainframe 'upgrade' to their M204 software systems. All worked as it should have in the testing environment with 50 users but on the day it went live with 15,000 users it crashed and burned in 10 minutes. The mainframe just did not have the capacity to service all the requests from users. This 'disaster' left everyone off the air for 4 days, while to entire 300 strong development team was thrown at optimising the 20 or so critical functions that were using all the cpu cycles, and a heap of additional processing capacity was purchased and installed. Like many huge implementations, this one took 2-3 days of processing to convert data and a rollback would have meant a delay in implementation for at least 12 months (Christmas only comes once a year and Easter was required for stage two), leaving the organisation with a software set which did not conform to statutes. This is truly a worst case scenario, but I mention it here so that you seriously consider the implementation phase. It is perhaps more critical than the actual development. If it leaves a sour taste in users mouths, you will have ongoing problems with users blaming the software for ALL problems, even their own short comings. Matt ----- Original Message ----- From: "HouseDad" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Saturday, April 16, 2005 12:13 AM Subject: [vbhelp] Application Renovations > > > > Ok, just trying to get prepared for the next big project. I may > actually be able to talk the company into buying some new software > for this one. > > What exactly will SQL server allow me to do? Will this elminate > the problems I have with big database file sizes? Basically I'll be > dealing with lots of individual files which will need to be created > and edited easily. Is SQL what I need to be looking at? > > Also, with handling multiple forms, is it possible to handle the > keypress/keydown events from a main routine so I don't have to copy > this code to each form? It would seem like the better approach, if > possible, if nothing else for minimizing problems with changes made > to code having to be in many places instead of one. > > Basically we're operating on a network with about 30 stations, and > the multiple operators will be creating multiple files on a folder on > the server. I have been given the task of completely writing new > software to take the place of the applicaton the company has been > leasing for 4 years. I feel a little intimidated as we'll be > dropping the leased application entirely and everything will depend > on my programs, not just select jobs as in the past. > > If I could get a little direction in what approach to take, I can dig > in and get the job done, but I really don't know where to start. I > don't think my current programs using access databases are going to > be sufficient. > > What are some approaches you all have taken with similar projects in > the past? > > [C] > > > > > > > > '// ======================================================= > Rules : http://ReliableAnswers.com/List/Rules.asp > Home : http://groups.yahoo.com/group/vbHelp/ > ======================================================= > Post : [email protected] > Join : [EMAIL PROTECTED] > Leave : [EMAIL PROTECTED] > '// ======================================================= > > Yahoo! Groups Links > > > > > > > > > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.9.11 - Release Date: 14-Apr-2005 > > '// ======================================================= Rules : http://ReliableAnswers.com/List/Rules.asp Home : http://groups.yahoo.com/group/vbHelp/ ======================================================= Post : [email protected] Join : [EMAIL PROTECTED] Leave : [EMAIL PROTECTED] '// ======================================================= Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/vbhelp/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
