Selecting from a Combobox makes Access 2003 crash after SP3

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

After SP3 for Office 2003 was installed last Thursday we have had some
problems.

One of the problems are that Access2003 crashes when we try to select a
value from a ComboBox.

We use many different ADP files, each connected to a database on our SQL 2k
server.

On a few of these projects, we are unable to select values from a certain
combobox.
The form opens up ok, all the boxes are filled with the correct values.
One of the boxes, say "cbxReply", has 2 values. An event (change) is
connected to that through VBA code.
If we try to select a value from that box, Access crashes. Ãf I set a
breakpoint on the change event, I can see that Access crashes before I even
get to there.
But, if I add some code to the event "Before Update", then the code runs as
normal and it seems to work just fine.

But the exakt same code seems to work fine on our other running projects.
Im at a loss here as to what the cause may be... ?

For some reason, on this case, Access must lose its way while trying to
figure out what event to handle, and then crashes...

Suggestions?
 
Try changing the RowSource of the ComboBox to something else similar. For
example, if it's the name of a SP, then try replacing with an EXEC statement
that it's changed every time the parameters are changed (for example, on the
OnCurrent event of the form).

Any particular field in the query, for example a bit field or a decimal
value?
 
Hi.
Thank you for your reply.
The rowsource is a simple Select.
And it works in many other, exactly the same, projects.
It's a "SELECT A,B from <Table> WHERE <integer DatatypeField> = 1"
2 columns, bound column = 1, column width = "0cm;10cm"

The Combobox is situated in a TabControl
We use the exakt same layout on the other 3 comboboxes on the other 3 tabs.
"SELECT A,B from <Table> WHERE <integer DatatypeField> = 2"
and then 3
and then 4.
All of these work fine.

The symptom does not occur on computers that do not have SP3 installed.

----------------------------
Another Problem:
We have discovered yet another problem after SP3.
We have 2 checkboxes, say "cb1" and "cb2"
And 2 textboxes, say "text1" and "text2"

On the event Click on cb1 the follwing code exists:
If Me.cb1.Value = True Then
Me.text1.Value = Date
Else
Me.text1.Value = Null
End If

and the same code for cb2 updating text2.

For some reason the state (true/false) of the checkbox is no longer updated.
Access just enters the Click_event without first doing what the inherent
function of a checkbox is, to toggle between True and False.

The symptom does not occur on computers that do not have SP3 installed.

--------------------------
The same thing about the bit CustomerLocked problem.

The symptom does not occur on computers that do not have SP3 installed.


All of these symptoms started last Thursday, when SP3 was installed.
So something in SP3 confuses Access majorly!
 
A good suggestion would be to rollback to SP2. Personally, I don't have SP3
installed and it's no longer my intention to install it anymore.

Look like that with SP3, there is some kind of memory corruption problem or
something on the same line. By any change, are you making calls to
..RecordsetClone instead of RecordsetClone anywhere in your program? In SP2,
I've observed a lot of strange things happening after the use of
RecordsetClone.
 
By any chance, have you set any custom property on the fields A or B on the
table; for example by setting a sorting order or a width for the column when
the table is opened/displayed in the database window?
 
Sylvain Lafontaine said:
By any chance, have you set any custom property on the fields A or B on the
table; for example by setting a sorting order or a width for the column when
the table is opened/displayed in the database window?
Click to expand...
 
The bit field and checkbox issue seems to be being caused by a differenec
between signed and unsigned values. Bits are unsigned and therefore not
boolean. Checkboxes are boolean and therefore signed. Changing the bit
field to a small int and the problem disappears. If you need to keep the bit
field then instead of a checkbox try a combo box with 'True' and 'False' in
it as values. Not nearly as nice but it does work.
 
The particularity that the value of True equal -1 in VBA is well known;
however, this doesn't explain why the automatic conversion of this value to
1 when bound to a bit field on SQL-Server was working perfectly well before
SP3 for Office 2003 but not after.

These last years, the support of this feature in ADP projects has been like
a rollercoaster: work, don't work, work again, don't work anymore, etc....
 
On some further work, specifically on the combobox issue, we found that
adding a 'DISTINCT' in the sql statement of the rowsource stopped the
crashing we were getting.

Really weird especially as the select only returned rows with unique primary
anyway. This simple addition has fixed all our problems with combobox,
well so far anyway.
 
Just to be sure: if your initial problem with the bit field and which has
been corrected with the use of the DISTINCT statement is related or not to
the installation of SP3 for Office 2003?

Also, are you using an explicit sql statement or a call to a stored
procedure for the row source?
 
Also, it would be insteresting to see if removing the DISTINCT clause now
will bring back the problem as it was before.
 
The combobox and checkbox issues only started after SP3 for office was
installed. We have a few machines which do not have SP3 and they were not
affected using the same adp.

The rowsource, generally, on our comboboxes where the problems arose were
with explicit sql select statements, either direct from tables or from views.
However, not all tables and views were affected and no reason for this is
obvious.
 
Did you take the precaution of decompiling the ADP project file after the
installation of SP3?
 
Back
Top