Results 1 to 7 of 7
  1. #1
    Bronze Lounger
    Join Date
    Jun 2001
    Location
    New York, New York, Lebanon
    Posts
    1,449
    Thanks
    1
    Thanked 1 Time in 1 Post

    INI Files in VB (VB 6 or VBA)

    <img src=/S/hello.gif border=0 alt=hello width=25 height=29> Loungers

    I have an up-coming project that I think will need an INI file emplementation.

    I need an example of how to read a highly structured INI file where I can take some Information, say a state's name, and populate a drop down and then once the user picks a state then another drop down is filled by the names of towns in that state, and then another dropdown is populated, once the user picks a town, with the names of all the schools in that town, and then once the user picks a school I want to read a URL, the one for that school's web site, and place it on/in the form and the user will click it and IE/Netscape will start and go to the web site.

    I can do all that in MS-Excel but my boss wants to distribute this application.

    Also a VB example of how to write back to the INI file because as new schools get web sites they need to be added.

    Thanks for any hints.

    Wassim <img src=/S/compute.gif border=0 alt=compute width=40 height=20>
    <img src=/S/compute.gif border=0 alt=compute width=40 height=20> in the <img src=/S/bagged.gif border=0 alt=bagged width=22 height=22>

  2. #2
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    INI vs. MDB for flexible data storage (VB 6/VBA)

    I think you're better off using an MDB file with two or three tables. There definitely is a learning curve for database projects, but you can count on Office 2000 users having at least a minimum set of DLLs (see <!post=Post #126363, 126363>Post #126363<!/post>). You might still have an INI file pointing to the shared path for the MDB file. If you don't want to use MDB format, you still can use ADO to write to an XML file ("disconnected recordset"). Then you'll really be on the cutting edge.

  3. #3
    Gold Lounger
    Join Date
    Dec 2000
    Location
    New Hampshire, USA
    Posts
    3,386
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: INI vs. MDB for flexible data storage (VB 6/VBA)

    You cannot count on Office users having Access.
    Unless one has a license to distribute the Access runtimes, you cannot distribute Access solution,

    You can distribute a VB 6 solution if you distribute the VB run time package, do you have a license for this?

  4. #4
    Super Moderator
    Join Date
    Dec 2000
    Location
    New York, NY
    Posts
    2,970
    Thanks
    3
    Thanked 29 Times in 27 Posts

    Re: INI vs. MDB for flexible data storage (VB 6/VBA)

    Howard,

    I was under the impression that the ADO library was a separate animal from Access, and that while you might need Access to create and update the .mdb file, the users don't need Access in order for the code to work, as long as they have the ADO library and the .mdb.

    Was this impression mistaken?

    Gary

  5. #5
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: INI vs. MDB for flexible data storage (VB 6/VBA)

    I meant to use an MDB as a data container and read/write with ADO. Access is not required for a VB(A)-ADO solution. My O2K Small Business Edition clients have no problem with ADO-based solutions hosted in Word VBA, and do not need extra controls, installs, or runtimes if they have the SR-1 update. I don't recall the change in SR-1, but I do remember that anyone who didn't have it ran into some problem. If someone is completely bereft of MS Office, they can download MDAC; I don't recall whether that is redistributable.

    For development, it is desirable to have Access, so you can design/modify tables and queries interactively.

  6. #6
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: INI vs. MDB for flexible data storage (VB 6/VBA)

    I'm confused Jefferson. Are your Word VBA solutions using an MDB, or just using ADO? The two don't necessary go together, since ADO can address all kinds of "data", not just database stuff.
    Charlotte

  7. #7
    Super Moderator jscher2000's Avatar
    Join Date
    Feb 2001
    Location
    Silicon Valley, USA
    Posts
    23,112
    Thanks
    5
    Thanked 93 Times in 89 Posts

    Re: INI vs. MDB for flexible data storage (VB 6/VBA)

    This particular solution is a Word template that reports data from our timekeeping program. The program's native report is, shall we say, crap. I use an MDB as an intermediary file because I don't want to touch the third party MDB directly. More specifically, in order to perform an outer join on some badly designed tables, I needed to run an intermediate query, and as I understand it, that is best done with a saved query. So my MDB has 3 linked tables, one local table, and 8-10 saved queries. Once I crossed the bridge, I found many nice things about having my own MDB, including the luxury of not re-querying the source DB (stored on a network drive in many cases) for multiple reports covering the same date range (I copy the relevant data to the local table first with an update query).

    When the user runs the template the first time, it looks for my MDB and if it doesn't find it, it simply copies a fresh one from a network server. I use ADOX to update the table links every time the report is run, since the solution allows one to tap into any timekeeper's database that is stored or backed up on a certain network share. (I think it was the ADOX that required SR-1.)

    This started out in 1999 as a DAO application with no local MDB; converting it to ADO was basically unnecessary, but since I had intimate knowledge of all of the other parts of the puzzle, it made for a good exercise.

    Becoming bolder in my advancing age, I have a second solution that takes data from a precisely laid out table in a Word document and, after presenting listboxes for certain things and cleaning up and validating the data, updates it directly to the program's database. In that case, I actually read the valid clients and matters from a third database after determining whether the local copy is fresh or needs to be refreshed from the network. Great fun, and so far, no serious problems. (I have a couple of utilities to address the crazy problems that the program causes for itself, or that users cause, but that's another story.)

    More than you wanted to know, I'm sure! If all progress in software arises from dissatisfaction with the existing program, you could say this has been one of the most inspiring products I have ever used. <img src=/S/grin.gif border=0 alt=grin width=15 height=15>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •