Replies

My thought then would be to have the new form in a “patch” MDB file and moved in automatically when the software detected a new version available. Only drawback to this is database bloat.

You would also have a problem if your using MDE’s as you would not be able to recompile the app.

Jim.

Wendell,

and the only goal is to propagate changes in the main form to the various application databases?

Jim.

The part I don’t understand is:

“using several subforms that are linked dynamically”

Do you mean you modify the master/child links and change recordsources, change controls or what?

In other words I don’t understand why the whole main/subform combination cannot be in the MDA and called from the main database. Why do the subforms have to reside there?

Jim.

Checkout the following MSKB article:

http://support.microsoft.com/default.aspx?…b;EN-US;Q120907

Jim.

Not in anyway that I’m aware of. The SourceObject property expects the object to be within the current database.

If you explain in a bit more detail what it is your trying to do (for example why the subforms must remain in the main database), I might be able to offer other suggestions.

Jim.

This is quite possible. Besides the solution offered, there is also a MSKB article with a similar solution, but it uses a table rather then an array to store the page numbers.

It boils down to forcing the report engine into 2 passes, the first is used to pickup the pages, the 2nd to format a control with the number.

Jim.

The reference to the table limit was the fact that if you bump into the 255 limit, then delete some columns, you can’t add more until you compact (resetting the internal pointer).

As for the forms, that’s the way I remember it. Could be wrong though (old age is setting in). But keep in mind that there is a difference between the types of compacts you can use. The one that fully compacts a database is the compact from the tool bar in the UI. Calling compact from code or using JETCOMP doesn
t do the job. Only Access knows what’s in a form object and how to handle it. When you call the other two methods, your letting JET handle the compact.

This is very critical now with A2000 and up as the VBA project file is now stored as a single row. JET can’t do anything with that.

Jim.

You’ll have to type a few examples. I don’t see any files attached to your last message and I wouldn’t know how to get them anyway as I rarely come here.

Jim.

Hi Mark,

I’m working on the same problem at the moment. Was testing some embeded word document extract code and discovered that my link between A97/Word 97 is broken.

A couple of comments on what I’ve come up with so far:
1. MSFT doesn’t have anything on this in the MSKB.
2. Word 97 re-registers itself (as most of the other office apps) whenever it’s started, not at install, so re-installing does nothing in this regard.
3. Install of multiple versions of office does not cause the problem. I’ve got 4.0, ’95, ’97, and ’00 all installed on one PC and this was working fine. I’m not sure what broke it at this point). This PC is my sandbox, so it’s got a lot on it (i.e. Visual Studio).

I’ve come to the conclusion that it’s some registry keys that have gotten messed up, but I’ve yet to try a re-install of Office 97 using /y. The /y switch forces a rewrite of the registry keys. What most don’t realize is that Setup will skip rewritting the registry if it dectects a previous install. I’m going to try this a little later today. Will let you know if it clears up the problem.

Jim.

You can compact the MDB, which removes the internal references and get up to the full 754. Same applies to tables and queries.

Jim.

You can either write multiple queries or you can call a function in the query and supply the right code. For example, the update to would be defined as:

=GetNewCode([BrokerCode])

and the function:

Public Function GetNewCode(strBrokerCode as string) as string

Select Case strBrokerCode

Case “AAAAAAA_”

Case “BBBBBB_”

End Select

That’s one way to handle it.

I don’t have enough info to give you other alternatives. For example, if their all the same length, then you could just check for the extra character on the end and strip it off.

or is it always a “_” on the end that’s the problem? If so, you could perform a criteria check on that and strip off the extra character.

The function though is a way to handle the translation of the codes on a case by case basis.

Jim.

And those errors would be what?

It would help when you posted questions if you did a little more work and supplied some detail.

Jim.

Well you’ve got 2 choices then:

1. Run update queries in your extract database before running any reports to update the sub fund data.

2. Base your reports on the data in the main fund records and ignore the data in the sub fund records

Jim.

Actually, it’s fairly painless. When you first start using A2000, ADO is the default data lib instead of DAO, so you’ll need to uncheck that reference and check DAO instead. If you want to use both DAO and ADO, then you’ll have some work to do as in the code, you’ll need to explicitly indicate which lib Access should use. ie.

Dim rst1 as DAO.Recordset
Dim rst2 as ADO.Recordset.

Outisde of that issue, the only thing you *might* consider doing is using /Decompile to make sure the BA project is clean. But I’d do that only if you triesd to convert and had problems. Just make sure that your A97 MDB can be compiled without errors before you try converting.

The MSKB on Microsoft’s web site does have a couple of nice articles on converting to A2000.

HTH,
Jim.

All changes will need to be made through a form on the main fund records. then in the Afterupdate event of the form, you’d run code or update queries to update the data in the sub fund records.

and yes, it is a poor design if the data in the sub fund records cannot be considered historical for this exact reason, which is called an update anomaly.

Jim.