Would appreciate a high level non technical Visual Basic overview with supporting Access database in an NT environment, and the differences between an NT and UNIX operating systems.<br>Thank you very much
There are 2 general ways that VB has to interact with an Access database. One is to use the data control and the other databound controls. This way is fast and fairly easy but is limited. The other is to dimension databse objects then use the DBEngine. ex:<br><br> 'dimension DAO objects at module level<br> Global ws As Workspace<br> Global db As Database<br> Global rs As Recordset<br><br> 'then in event handlers you can open databases, recordsets, etc.<br><br> 'create a workspace<br> Set ws = Workspaces(0)<br> <br> 'open a database<br> Set db = ws.OpenDatabase(app.path & "\Some.mdb", False, False, dbLangGeneral & ";pwd=nice_try"<br><br>'you can now insert into tables or use any SQL.<br> db.Execute " INSERT INTO MyTable IN 'a:Some.mdb' SELECT * FROM SomeTable WHERE Subject = '" & dbcSubject.Text & "'"<br><br>
Using the DBEngine object and its methods, collections, etc. allows a VB program to do fancy things like create DBs, create, modify and delete tables within DBs, report on the DB structure, etc.<br><br>Using the data control is usually much easier if you don't want to play with the DB structure. I prefer not to use bound controls as changes to them are applied immediately to the DB. But you can use the data control without using bound controls, e.g.<br>* use the data control to build a recordset and move through it.<br>* assign the columns of the current record to unbound controls, e.g.<br> TextBox1.Text = DataControl1.Recordset("Field1"<br>* validate any changes made by the user.<br>* set the columns of the current record from the unbound controls, e.g.<br> DataControl1.Recordset("Field1" = TextBox1.Text <br><br>Sometimes you want to use a particular type of Active X control and this may force you to use one approach or the other.
zucchini -<br><br>BruceHesher and philca have addressed the data control subject very well. Access can be used in a multi-user database, but tends to run out of steam at about 4 users (YMMV). We use it for storing user & application specific data. Like if there's some configuration info that is too big, or too awkward to put into the Windows Registry or a .INI file, we'll use an Access database. We also make sure there's a way for the support desk to have the user rebuild the Access database should it become corrupt (we ship a small program that that's all it does, or sometimes add a command-line switch to rebuild the database, etc).<br><br>Anything beyond this, we spec a larger database, like Oracle or MS SQL Server. Sometimes it's overkill, but they're much sturdier than Access. Mostly, it comes down to preferences of me and the other developers.<br><br>Regarding the differences between Unix and NT. The big one is that NT is single-user. You can buy multi-user add-ons like MS Terminal Server or Citrix WinFrame, but they're still add-ons. Reliability of both is pretty good, but a well-run Unix box is still much better than a well-run NT box (we have to reboot our NT Servers about every 2 weeks for preventative reasons). The development tools available for NT give the developer a much more productive work environment. At the same time, they tend to hide some of the low-level details that a programmer needs to know about and/or fiddle with. Microsoft does a good job of passing out SDK info via their MSDN subscription. The Universal Subscription is very cool, albeit expensive ($2499 per user per year), because you get a copy of all their operating systems, development tools, and most productivity apps. Biggest problem with MS right now is the uncertainty with the results of the Justice Dept. sanctions. That, and their coming out with new development platforms every year or so that obsolete previous releases.<br><br>Chip H.<br><br>
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.