Combo Box not working on install to newer system

[alpnz]

Today, I installed a MS Access application on a clients new computer, and received an error message related to Mscomctl2.ocx, ( It shows in the VB reference as MISSING) It is a MS Windows common controls ocx, used by combo boxes and lists inside the application. What I want to know is are there any issues with me downloading the missing ocx and registering it on the new computer, which I assume has the latest version of Windows, and Office.?
Secondly, can anyone offer an alternative way of referencing data in an Access form. I have read with interest the thread related to IE7. As a user of SuSE in our own operation, I have to admitt to some eye rolling after reading that Thread. :-)

JD

[MMcCarthy]

Today, I installed a MS Access application on a clients new computer, and received an error message related to Mscomctl2.ocx, ( It shows in the VB reference as MISSING) It is a MS Windows common controls ocx, used by combo boxes and lists inside the application. What I want to know is are there any issues with me downloading the missing ocx and registering it on the new computer, which I assume has the latest version of Windows, and Office.?
Secondly, can anyone offer an alternative way of referencing data in an Access form. I have read with interest the thread related to IE7. As a user of SuSE in our own operation, I have to admitt to some eye rolling after reading that Thread. :-)

JD

In theory, one option is to have the ocx file in the same folder as the database and Declare a reference to it under option explicit.

If you can download and re-register the ocx I would try that as it's available from then on. First though, check the list to see if there is another version of the file available. If the version is newer or older it won't automatically pick it up you will have to manually select it.

[alpnz]

In theory, one option is to have the ocx file in the same folder as the database and Declare a reference to it under option explicit.

If you can download and re-register the ocx I would try that as it's available from then on. First though, check the list to see if there is another version of the file available. If the version is newer or older it won't automatically pick it up you will have to manually select it.

I agree, the option explicit, would suffice. I am reluctant to risk incompatibility, with new versions of windows, and in particular browser security issues. (See thread on IE7 this site, I take it from a quick read that MS saw older ocx applications as security risk, to have disabled them ... perhaps I have misunderstood the issues) The other option is to of course rewrite the application, which started life in Access97, and has had re-lifes over the last 10-12 years. The dream of course is to write it all in PHP and supply the application in a LAMP environment. Sadly this old monkey, is to old to learn new tricks. It is a very popular application locally, and the problem we might face is that a greater user audience might want to use it, and that would be a logistic challenge.

[alpnz]

In theory, one option is to have the ocx file in the same folder as the database and Declare a reference to it under option explicit.

If you can download and re-register the ocx I would try that as it's available from then on. First though, check the list to see if there is another version of the file available. If the version is newer or older it won't automatically pick it up you will have to manually select it.

Hmmm had a better read of your reply, which had so much more in it the second time thru. I recall a number of newer ocx, not ticked. I presume that you mean newer objects are reverse compatible and will recognise their ancestors?.

[MMcCarthy]

Hmmm had a better read of your reply, which had so much more in it the second time thru. I recall a number of newer ocx, not ticked. I presume that you mean newer objects are reverse compatible and will recognise their ancestors?.

Usually, but no guarantees on that.

Mary

[alpnz]

Usually, but no guarantees on that.

Mary

OK the old ocx is registered, however the forms are not functional.
E.g.I have a Form which shows parent items and a subform, with related sub items, On the form is an "edit" sub items button which opens a form with the sub items related to the parent item, in a continuous form, with combo boxes on fields , which allow selection of different values from related tables, in the old Access 2000 database all worked well, and you were able to edit sub items field values, and close the form, refresh the Parent items form, and all was hunky dory.

Upon loading the upgraded to Access 2003 database onto a new computer with Windows XP and Access 2003, the combo boxes do not work, nor can you edit any fields in the other 40 odd forms in the database.
Have i missed something really obvious???.

Very puzzled. One last ditch option, is to take the old Access 2000 application, load it on the new platform and upgrade on the new platform. Perhaps the ocx would sort itself out?

JD

[MMcCarthy]

It sounds like your forms have been locked. Check the locked property on one of the forms in design view and make sure it hasn't been set to Yes.

Otherwise create a new test form in the database and see if the objects work as expected. If not the problem may be one of security privilage.

If either of these don't work come back.

Mary

OK the old ocx is registered, however the forms are not functional.
E.g.I have a Form which shows parent items and a subform, with related sub items, On the form is an "edit" sub items button which opens a form with the sub items related to the parent item, in a continuous form, with combo boxes on fields , which allow selection of different values from related tables, in the old Access 2000 database all worked well, and you were able to edit sub items field values, and close the form, refresh the Parent items form, and all was hunky dory.

Upon loading the upgraded to Access 2003 database onto a new computer with Windows XP and Access 2003, the combo boxes do not work, nor can you edit any fields in the other 40 odd forms in the database.
Have i missed something really obvious???.

Very puzzled. One last ditch option, is to take the old Access 2000 application, load it on the new platform and upgrade on the new platform. Perhaps the ocx would sort itself out?

JD

[alpnz]

It sounds like your forms have been locked. Check the locked property on one of the forms in design view and make sure it hasn't been set to Yes.

Otherwise create a new test form in the database and see if the objects work as expected. If not the problem may be one of security privilage.

If either of these don't work come back.

Mary

My thoughts exactly, and having a spare hour yesterday afternoon, I visited this site, and did just that. And well yes the combo boxes work on a new one, so this tells me that something is amiss with the older form. I started pruning the underlying query, and upon the removal of a related table, lo and behold the form starts to work. Re insert the related table and it loses function. This is really strange. I ran out of time, but what I think I need to investigate is locking between the frontend and the data file. In that the offending table has permissions on it or something. One possibility is that it lacks a timestamp, but that should not affect it, if there is only one front end.
What I cannot understand is that it works fine on the older platform. Being a Linux oriented IT person, I find this all very frustrating. And so typical of trying to support M$ applications.

[NeoPa]

And so typical of trying to support M$ applications.

Lol - had to reply to that.
I had a thought that may be off target but may be worth checking.
Is the underlying query updatable in both cases?
I'm not sure what all the criteria are for Access deciding a query is updatable, but it may well be different depending on the links to the back-end.
Some ODBC drivers are R/O for instance.
It's somewhere to check anyway. You'll know if the recordset is updatable if you run it stand-alone and it has an empty record slot at the bottom with an '*' denoting add new record.

[alpnz]

Lol - had to reply to that.
I had a thought that may be off target but may be worth checking.
Is the underlying query updatable in both cases?
I'm not sure what all the criteria are for Access deciding a query is updatable, but it may well be different depending on the links to the back-end.
Some ODBC drivers are R/O for instance.
It's somewhere to check anyway. You'll know if the recordset is updatable if you run it stand-alone and it has an empty record slot at the bottom with an '*' denoting add new record.

Now thats a good point you make. This application is installed around a number of different sites, and has evolved from Pre historic Access. I have run the application against 2 or 3 servers, including MySQL which worked OK, and MSSQL which was a bit of a learning curve for such a simple task. two or three including this install and another yet to happen, I run against a mdb file, because servers are not available. This is OK, as long as I don't overdo the users. Perhaps I inherited some sort of R/O setting, due to copying from a server site to the development site. I have no recolection of setting queries to RO in the past, but then this sort of support, does give you Alzthiemers .... :-)
More to follow, I am about to mount my stead, and head of to this site right this minute, and do battle with the beasty.

[NeoPa]

More to follow, I am about to mount my steed, and head off to this site right this minute, and do battle with the beasty.

Excellent, like the medieval reference, captures a good spirit.
Good luck - unfortunately, while determining if a query is R/O is fairly straightforward, finding out why it's not can be a right royal PITA.
Good luck on your endeavours Sir Knight.

[alpnz]

The dragon has some life in it yet. Funnily enough my client wanted some changes made, which required a whole new layer in the core part of the application, resulting in a fairly major rework. (Which is good) The result of course requires new forms, which, leads me ever so gently away from the problem. I have actually visited a MSSQL site, and had a bit of a wonder through the code, and still do not understand what has actually happened. It has to do with the transfer from one version to the other, that much I have established, as I have replicated the problem, by copying the frontend from one site which is Access 2000 to the new one which is Access 2003. It has been an interesting experience, as I did happen to rate myself as some sort of "knowledgable old git" on Access. Goes to show that class is never out. :-)

[MMcCarthy]

The dragon has some life in it yet. Funnily enough my client wanted some changes made, which required a whole new layer in the core part of the application, resulting in a fairly major rework. (Which is good) The result of course requires new forms, which, leads me ever so gently away from the problem. I have actually visited a MSSQL site, and had a bit of a wonder through the code, and still do not understand what has actually happened. It has to do with the transfer from one version to the other, that much I have established, as I have replicated the problem, by copying the frontend from one site which is Access 2000 to the new one which is Access 2003. It has been an interesting experience, as I did happen to rate myself as some sort of "knowledgable old git" on Access. Goes to show that class is never out. :-)

I know what you mean. My 2000 is like a comfortable pair of shoes and luckily most of my clients still use it. There is so much more funcionality in 2003 and I believe even more in 2007 that I know I'll have to make the permanent move eventually.

Why do MS keep "improving the environment". It's being more and more targeted to the non developer. As a staunch defender of the ability of Access and VBA to operate as a true database environment (barring size of course) I would have liked to see them incorporate more of the Developers edition into the Access functionality.

OK that's my rant for the week.

Sorry about that.

Mary

[NeoPa]

Don't be a stranger then Alpnz - We need more 'knowledgable old gits' around these parts.
We should stick together.

[alexherrero]

I know this is not exactly what is expected for an answer to this thread, but I suggest you to have a look to "Late binding". Maybe you know what I'm talking about, but it could be of help to avoid "MISSING" components on an Access database:
Tony's tip: Late Binding

[MMcCarthy]

I know this is not exactly what is expected for an answer to this thread, but I suggest you to have a look to "Late binding". Maybe you know what I'm talking about, but it could be of help to avoid "MISSING" components on an Access database:
Tony's tip: Late Binding

Good suggestion.

And please feel free to post in any thread in this manner. You're reply pertains to the original question and even if the original poster doesn't need the answer any more. It will be useful to others with the same question.

Mary

[alexherrero]

Good suggestion.

And please feel free to post in any thread in this manner. You're reply pertains to the original question and even if the original poster doesn't need the answer any more. It will be useful to others with the same question.

Mary

Always trying to help!

Thanks!

[alpnz]

Thanks for the input, it is most appreciated. I'm with you Mary on the Developer tools. One of the really interesting enchancements I have had a quick look at, is the ability to use Small Business Manager tags (Correct me if I'm wrong someone). My application has virtually had the frontend Forms rebuilt, due to a fundemental difference in how the client wanted to use it. I best fess up and tell you something about it. Many Many years ago, I was approached by a Fruit Packing operator, with a request to tidy up his spreadsheet. I should have smelt a rat when he said spreadsheet in the singular sense. I was presented with a spreadsheet about half an acre in size :-). The rest is history as they say.

[alpnz]

Now where did I put that PHP for Dummies book :-)

[alpnz]

Just to round up on this issue.
It transpires that M$, have stopped installing some of the more ancient and useful ocx components as default, upon install of its newer products. I can only presume that it is to prompt ancient old developers to get into the 21st century. This matter was resolved by installing some of the older commmon control ocx's used in most of the forms in the application. If you have read this far then, checkout in particular your references under the visual basic editor.

JDS