Replies

Hans:

The article references a setting of 0 (zero) to mean all records .I tried that, and it did not seem to work. So I set the registry key to a value large enough for me, and it work very nicely.

Once again, thanks

Murad

Hans:

Thank you very much.

I turned my data file up side down, and let publisher do it the way it wanted to, so I have not tried what you suggest at this time. Will let the group know if it does not work.

Once again thank you very much for the prompt response.

Murad

Hi:

I’d like to expand on this idea little. I’d like to add some additional fields to the default form, and not have to tell Outlook 2003 which form to use when creating a new contact or opening existing ones, in ALL contact type folders, and I don’t want to loose any of the existing functionality vis-a-vis the setting of flags and such. So lets start with the first order of business. Modifying the default contact form. Is that even possible? When I attempt to invoke the form designer, the form that is displayed is quite different than the default contact form I see with Outlook 2003. What gives?

I could just…..

Thanks. I would never have guessed. It appears that ZoneAlarm was getting in the way. Not quite my Antivirus, but close enough. I

Gramps, welcome to the conversation. I’m going to feel like a total idiot if I’m in the wrong room altogether. I keep making confessions as to the wisdom of the technology I support, but yet we seem to be stuck on why can’t you do it some other way. You are all correct, Microsoft Access 2000 (am I in the correct forum?) is not being used as it might. The tables in the DB are empty, they get populated by our client application when a user elects to enter data into their custom forms. I should not have used the phrase “nothing about the customers forms changed”. I’m not concerned about security. I tried to explain, that my job is to test the darned product, specifically installation testing. The customers forms are getting corrupted during the product upgrade process. During the installation/upgrade, the exising DB is saved, a new one dropped onto the target machine, and an Access Macro is run. The macro imports the users custom forms from the old database, and we’re in business. I need to devise an automated way to extract the definition of the users forms (controls and properties of controls) and verify that they remain the same before and after running the product upgrade setup process.

I’m not sure what sorts of forms you’re thinking of, but ours are very simplistic. Like I said in a previous message, the purpose is simply to allow our users to fill out information on screen that they are used to filling out on paper. The tables simply serve as a conduit to the host database which is actually something called UniData. Before you ask, there is not OBDC mechanism to talk to UniData.

Hope that clarifies the situation some.

Thanks again for the responses. Where does one begin….
My job as a QA automation engineer is to develop an automated mechanism (hence the command line, because it needs to tie into our existing automated strategy) to ensure that forms in an Access DB migrate correctly with each release of our product. Our product is not an access product, it does have a front, and uses access to present host data to the client in forms they are comfortable with. Customers create forms tied to data in a fixed set of tables they are not permitted to modify. They are not allowed to write macros or create modules. Whenever they create a form, they are required to create a record in a specific table so we know that a custom form has been created. It gives them a warm fuzzy feeling to fill out a loan application on that looks exactly the same on the computer as the paper version they’ve been filling out for years. They create a form, scan in an image (actually they pay others to do this for them), place transparent fields where data is entered/displayed, and now they can process the form electronically. The data is retrieved from the host and temporarily stored in this Access DB. The forms they create autofill with certain data from the tables. Data that is entered into the forms is stored in the tables (and eventually pushed onto the host). Forms may contain user defined fields that are based on other fields on the form, or on other custom forms. Supporting tables exist to allow this to work. Access is not being used to store real data, it’s merely being used as a conduit to allow our brain dead kludgy system to appear high tech.

Now back to my issue. Mark, I think you hit what I was looking for, (Charlotte, I know you know this also but I did not make myself very clear). I need to “loop through each form in the database, and in turn loop through all controls on each form”. Correct me if I’m wrong, button, edit boxes, checkboxes, images are all examples of controls, and each has properties associated with it? I call them objects, but controls works just fine. Okay, so how do I write a C/C++ console application that can open an access database, select from a table that contains the names of the users forms, obtain all properties of all objects on this set of forms, and save it to a text file or another database (which the application could create) for later comparison. Again, remember I’m in QA, extract the info, run the upgrade process, extract the info, and compare the before and after data. I would write the application to read command line operators because the upgrade process is an independant task. The command line to provide the name of the datafile to be created or compared.

With regard to MSysAccessObjects. I still don’t know the intended purpose of the table, but it seemed like it might be the repository for object/Control information. That’s why I wanted to query it. As for the data type, I don’t care since I’m interested in a comparison before and after, and all I need to do is throw up a flag if the two are different. So what information does MSysAccessObjects hold. Looping through each control would add the additional overhead of querying the control type, and then getting the property values for controls of that type. If there was a way to obtain in bulk all properties of all controls on a given form, that would be just perfect. I just need to barf if something has changed, the ‘what’ does not matter (at this time). Let somebody else figure that out later.

Change references to MSysObjects to MSysAccessObjects. That’s the table that has the ‘data’ and ‘id’ columns I was talking about.

Mark:

My previous post was in response to your message 209614. I just got your post from earlier today. Will look at your attachment. My answer is probably there.

Thanks Mark. I’m very inexperienced at this so please bear with me. How does this give me the properties of the objects on the form, and their attributes?

We give our customer a database. They are allowed to create forms in the database. When we ship them a new release, our installation procedure is responsible for installing the latest version of the database, and migrating the customers forms to the latest release of the database. My job is to check that the migration of the dataforms from the old database to new version of the database did not cause any corruption to the forms the customer created. The thought I had was to our table where the customer is expected to report the custom forms they have created. Then query the properties of each form, AND the objects on these forms for their attributes before and after a product upgrade and make sure that nothing about the customers forms changed.

To be quite honest, I don’t need to what changed, just that something is not the way that it used to be before the upgrade process. The MSysObjects table has a ‘Data’ column. I’m hoping that it contains the details of form objects and their attributes. It would be just fine with me if I could query the ‘data’ and ‘id’ columns of MSysObjects before and after, and complaining if the two are different.

After poking around the database for a while I may have an adequate solution (no code, just a concept at this time). There is a system table MSysAccessObjects. I suspect the ‘Data’ column of this table contains information about all objects in the database including all forms. The database has a table that identifies all the users custom forms. Now if I could just find a way to correlate these two pieces of information, I’d be in great shape.

I notice the table MSysObjects that contains a Name field that appears to contain a few rows with the names of some custom forms. I’m guessing that’s my correlation.

Now the key question is whether the ‘Data’ column in MSysObjects does in fact contain a codiefied representation of the objects (and their attributes) in my users custom forms. If so, I’m done. I’m not interested in the specifics of each object and it’s attributes. I just want to make sure that they were not altered by the installation of a new release of our software. Where I might get busted is if the codified representation includes references to other objects whose identity may be legitimately altered during the installation process, in which case, my test would result in a false positive.

Cheers, and a happy 2003 to those of you who are already there.

First the easy part. By ‘flat file’ I mean a text file. I need to extract the information below from the database in two passes, once before a software installation, and once after. I’m in the QA department in need to verify that an installation of our software (which updates the database) did not cause any corruption to the users forms.

From the command line, I need to query a table to get the names of the users custom forms. Now for the hard part, without knowing the structure of the users custom forms, I need to query the database (system tables, I guess), to find all the objects, on each of the users custom forms and retrieve all available attributes, and their values. I need to save this information to a text file. Once again, I need to do this from the command line or via a VB executable.