Re: Converting Access database to SQL server or Informix

While I where away an anonymous Access Developer wrote: The main issue here is *not* to argue with that poster, but make some issues a little clearer for other interested parties. The "questions" aren't meant to be answered. The answers are hopefully clear enough for most unless I have blundered somewhere which sure is more than possible. :I'd surely appreciate some specifics about why one might want/need :to move away from Access as a front end tool. I keep hearing people :say this, but usually they are quite vague about the _reasons_ that :Access would become unsuitable as a client application. Have you ever tried to run 1000 users connected to the same database using an MS Access front end? Did it work well? Did it give all users good response time? Would other solutions have given better responsetimes? Did you use a transaction monitor? Does MS Access support a transaction monitor well? Did you ever try with 10 users that wanted to count the number of selected rows with arbitrary SQL commands (user selected) and then insert say all customers found into another table, possibly in another database, all with several million customers in the database, each having a significant number of rows in many other tables of different types of data? Did you get good response times? Where you able to split the inserts into multiple smaller ones to avoide to long transactions and still get good response times? Did you try to create multi tiered applications with multi treading at several levels in MS Access? How did it work out :-) O, but VB can do that you say. Well, I would want to see that before I belive you realy get a well working application out of it. Anyway, you didn't want VB so that's hardly a question anyway. With some more work from Microsoft it's likely VB will work for developing such applications, but Java works now. Additionally that's where significant serious development is done all over the world to create better and better solutions in this space. Even Microsoft will have a hard time keeping up with that. There are many other examples, even at a much smaller scale, where MS Access is simply a toy. Of course for a significant number of smaller and simpler applications MS Access is a great tool. I have however never heard of anyone that have seriously tried to claim it as a tool for everything like you do. Even Microsoft doesn't do that. :I do know that creating the same client application in Visual Basic :as the ones I've worked on would be far more expensive in time, :effort, and third-party controls. That depends on the application and what you want to do. VB is also becoming simpler, better and faster with every release. Now mind you VB is only marginally better than MS Access. Other tools are required in many cases. :As far as I can see, there _is_ no :acceptable substitute for Access reporting available to the VBdeveloper. Now it's for reporting. For simple reports MS Access is just greate. In some cases Impromptu from Cognos is however better. Other tools exist as well that can scale better and do more than MS Access can. Have you however tried to print 100.000 invoices in one run and implemented a simple way of reprinting some or all of these without having to read all the data from the database again? Did it do logo overlays for multiple companies, printing one of a large number of letters with each invoice and have other such simple functionality. I wouldn't even try. :Assuming the server-side applications are not intended to run on Unix, May be you have to. I have yet to see a Windows NT solution scale to the power of a Sun Enterprise 10000. All I hear is that it stops way before this. :why would I want to learn yet another language, an interpreted (or :emulated, as someone strongly claimed, as though there was a :universal definition) one, at that? May be you should take a look. To the extent that you think you need it, you can actually compile Java to native code on many machines by now. However I didn't know that MS Access did that yet, so the argument isn't particularly well thought out. With VB you can - on Windows, but you said you didn't want to use that. A key issue is however that Java is more than fast enough for a large number of bussiness type applications. In these cases your database will allways be the "slow" part, so even interpreted Java isn't an issue. What is a significant issue is however the transportation of data. If you have any significant ammount of data to deal with you don't want to transport it over a network. Not even a high speed local network. Java is ideal in this case with it's simple options for placing objects where the data is. Soon we will even see Java runing inside the database engine from at least Informix. : With the VB language that we know :(and of which we use a goodly subset, VBA, in Access) we can :create COM components, You could, but it isn't quite as easy as Java server side objects and soon to come Enterprise Java Beans. There are also serious limitations as to it's scaleability as it's limited to Windows NT only. If you should claim that Microsoft is cooperating with others to make it run on Unix I would want to see you COM components written in MS Access -- err... VB, MS Access can't create them so you had to use VB instead as you said -- runing on Unix. C++ you say - feel free to try. I wouldn't. : and we could, if we so desired, even run :our Access apps under Citrix WinFrame or Microsoft Terminal Server :plus Citrix Mega-whatever). At what performance level? Did you check it out? This isn't quite serious, so I prefer to leave it at that. And did you try to create a batch mode program in VB? It should realy run as a service on Windows NT. Not easy although it may be possible for the advanced developers. Runing it as normal forground application doesn't guite solve the same problems. In a production environement you want something we could call a job control system to run things at predetermined times. Sure the at command exists in Windows NT, but that doesn't quite do it either. What is needed is a simple way for users to set up the jobs and have them run on the server where the database is located. Microsoft didn't make this easy. It has allways been easy to create such solutions on Unix. With Java it has however become easy to do even on Windows NT. : If you are tempted to quote "Write Once, :Run Anywhere", please spare us... laughing so hard tends to hurt :our ribs. I am sure your MS Access applications run without modifications on a Sun server (not on MS Windows connecting via ODBC or some such thing). You might want to check out Java a little better. We don't want "Run Anywhere", but we know we can run several places, and with great success. Also we can use the same language for client and server side development. We can easily move parts back and forth as we see what works best. We can use RMI or go to Corba if we should need that. If you didn't know both actually work very well by now. We also have the benefit of a large number of companies creating high performance large scale solutions arround these and other technologies that you might not have thought too much about ye