Access 2010 Bugs

[HansV]

If you want to attach a database, do the following:
- Create a copy of the database, and work with the copy.
- Remove everything that isn't necessary to demonstrate the problem.
- Remove all sensitive/proprietary informstion.
- Compact it (File > Manage > Compact and Repair Database).
- Create a zip file (compressed folder) from the database.
- Attach the zip file to a post or reply.
The maximum size for an attachment here is 256 KB.

[Charlotte]

However, that problem with controls with default values on unbound forms is a real pain. I hope it can be solved.

Mark,

I don't really see that as a bug, but that may be because I've spent the past few years working in VB.Net rather than Access. Logically, the control is doing exactly what you tell it to. The behavior is what I would expect in .Net, and the workaround would be to set the default value in code for each new record rather than in the control's properties.

[Mark L]

I don't really see that as a bug, but that may be because I've spent the past few years working in VB.Net rather than Access. Logically, the control is doing exactly what you tell it to. The behavior is what I would expect in .Net, and the workaround would be to set the default value in code for each new record rather than in the control's properties.

I don't see how this is working as expected. To me, the default value is the initial value that is loaded into the control when the form opens. It should not preclude me from entering a null value in the the control. If I wanted to stop that, I'd set a Validation Rule.

[Charlotte]

I think you might find that Microsoft considers it to be the value loaded into the control when the control is null, since that's the condition when you open the form and that triggers the value being loaded in the first place.

[Mark L]

I think you might find that Microsoft considers it to be the value loaded into the control when the control is null, since that's the condition when you open the form and that triggers the value being loaded in the first place.

That might be a reasonable assumption except that it wasn't their thinking in all the prior versions of Access. It makes no sense to change it now, so I have to assume it is a bug.

[agibsonsw]

Hello.
Not sure if this a 'bug' but when I previously added a calculated control to a form, that refers to other fields on the form, it would re-calculate all the time. I'm having to Refresh the form to get up to date values. Any idea why? Andy.

[agibsonsw]

Actually, one of the fields is from another table. I revised the calculation to refer just to the text boxes and it seems okay now.

But I do seem to recall that this used to work prior to Access 2010. Perhaps I'm mistaken? Andy.

[HansV]

I have code to recalculate in older versions, so I don't think this behavior is new in Access 2010.

[rmottern]

I've experienced the importexporttext error, where it does not recognized text specifications. It looks from its QA board that MS has known about this since at least June 2010, and has not bothered to fix it. I guess they believe that importing text data is not an important function of a database program, so its not worth their time to fix; or maybe they are just getting fat and lazy out there in Seattle.

I've run into another problem with text import, but I don't know if it qualifies as a bug. I get some text files daily that I need to import; they come in CSV format. When I click on the file, it opens in excel. The date shows in the column of data as: "11-Mar-11" In the box above that shows the value of the cell, it shows up as "3/11/2011"

Access 2007 had no problem recognizing this as a date, but Access 2010 will not. Actually, that's not totally true; when you open the box to create a file specification, it does recognize this as a date b/c it defaults to the date format data type.

I've tried every permutation of file specification to get it to recognize this as a date, but it always returns an error and imports the file with the date field blank.

It will import the field as a text file, but it shows up as "11-Mar-2011". I recognize there's probably something I could write to convert this into a date, but it looks like it would be a bear.

If I try to import as a number, you get the same error that the data type is not compatible.

If I go into the text file (in excel) before I import it and reformat the date field so that it shows up as "3/11/11", then it imports fine. I recognize that I could do this every day, but it would create a lot of tedious work that I would rather not do.

Is this a bug? or what am I doing wrong? or did MS simply decide to stop recognizing this format as a date? even though its recognized in all other offfice programs as a date?? I just upgraded to 2010 last week, and I'm not happy that it can't import text data.

[Mark L]

You might want to try change the file extension of those files to .txt rather than .csv, so Access won't assume it is an Excel file. This should give you the opportunity to change the import specifications when you go to import. You can then save the specifications to be used each time.

[Wendell]

I've experienced the importexporttext error, where it does not recognized text specifications. It looks from its QA board that MS has known about this since at least June 2010, and has not bothered to fix it. ...

You are correct that the problem has been known about for some time - see this knowledgebase article which has several workarounds. I rather expect the issue will be fixed in SP1 of Office 2010.

The other issue with importing dates in that format is not something I've seen reported previously. I see you have also posted in the Microsoft Answers forum, so perhaps one of the Microsoft folks can comment on that. In the meantime, Marks suggestion may prove useful - the format is not a native Access format, but is used by Excel.

[n52202]

I found a problem with exporting LARGE tables (over 65,536 lines) from Access 2010 to Excel. The first time I export it, the file exports without any problem. When I export it a second time (to the same file name), I get a pop up box that says the object exist, do you want to replace the existing object. I selected "yes" to replace the file. The next pop up box says "Can not expand named range". When I look at the excel file, it has the first 65,536 lines as blank (the data has been deleted) but starting with line 65,537 the old data is still there. Obviously the problem is Access does not clear the entire Excel file. Has anyone else found this problem?

[muskrat775]

The install seems to have a bug as well. My scenario:
Windows Vista 32-bit (Basic) SP2 (Completely patched up to date)
No previous version of MS office ever installed.
Open Office 3.2

I haven't done a whole lot of testing, but when installing Access only (All options) and changing the default install directory, the installer throws a "Side by side manifest error" with a GUID attached. After removing open office, trying to repair Access and removing/reinstalling, I still ended up with the same error. During 1 final attempt to install, I didn't bother changing the install directory and it worked. I was able to replicate this on another machine as well. It sounds like one of the developers may have accidentally hard coded the default install path in the manifest. There is a lot of bad information about this on the net, so I hope this helps...

[HansV]

Welcome to Eileen's Lounge!

Thanks for the info - the "Side by side manifest error" appears to occur frequently, judging by the number of posts about it in the Microsoft Answers forums.

[learner74]

I have an issue with fixed width text export files.

Specifically, the export specification is being ignored.

There is a similar query already raised here:
http://answers.microsoft.com/en-us/offi ... f6de157234" onclick="window.open(this.href);return false;

Here is a simple example of what I mean:-

Access 2010
version: 14.0.5128.5000 (32-bit)

1) Create a new table, 3 fields (a,b,c):

Field Name: Size:

a text (255)
b text (10)
c text (2)

2) Enter 3 records:

Field a data:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Field b data:

bbbbbbbbbb
bbbbbbbbbb
bbbbbbbbbb


Field c data:

cc
cc
cc


3) External Data\Export\Text file... Fixed Width... Advanced...

Export Spec:

Field Name:            Start:            Width:

a                    1                50
b                    51                10
c                    61                2


Save export spec. OK. Next, Next...Finish

Check the resultant export fixed width file.

It's not fixed width:-

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbcc
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbcc
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbcc

The field a record lines are not fixed to 50 chars at all, as in the export spec :(

Doesn't happen in Access 2007.

[HansV]

Welcome to Eileen's Lounge!

I don't know what the Access 2010 development was smoking when they worked on import and export specifications, but they introduced an unusually large number of bugs... Let's hope they get fixed in the upcoming SP1.

[n52202]

"The text file specification "#" does not exist. You cannot import, export or link using the specification."

Microsoft has completed a solution to this problem. The company I work for has the patch and I have successfully tested it. Hooray!

[HansV]

Good to hear that - thanks for the update!

[als]

New Access 2010 Style of button seems to be lost if you change it's BackColor and remains if you change only ForeColor.
Sample for testing can be downloaded here:
<link removed>

[HansV]

Welcome to Eileen's Lounge!

The link that you posted required downloading of a .exe file. We'd rather not force users to install software in order to download a file.
You can attach zipped Access databases to a reply here, with a maximum size of 256 KB. See Tip: adding an attachment using the prosilver skin.