Replies

Use an ‘image’ data type.

This ‘image’ data type will hold binary data including ms word, and excel documents.

For more information you can find details in books online (downloadable from MS).

Cheers

Along with explicitly declaring either ADO or DAO, make sure that you have the DAO library referenced in the project.

From the VBA Window, goto Tools –> References and check (select) the Microsoft DAO 2.6 reference.

Cheers

Jayden

I notice that you have used the values (2,4,6) etc, instead of using vbMonday etc.

Just a small point that I thought that I would comment on.

This isn’t the best thing to do, because it isn’t guaranteed that later versions of Access will have the weekday function that returns the value for Monday evaluate to 2 – but it should always evaluate to the vbMonday constant. This is why MS include these types of constants.

Cheers

Jayden

Do you have both 2000 and 2002 installed on the same machine?

I wonder if this could be the cause, as I found that having 97 and 2000 installed on the same machine produced funny things like this also.

Jayden

I think what it looks like you need is actually a ‘work-order’ table, with the work-order number an auto-number field. The work-order table would be in a one-to-many relationship with the customers table, with the customer table being the one side of the relationship.

The work-order table would contain the customer number, the work order number and any details you wish to record about that particular work order itself.

I think that you are perhaps going about it the wrong way wanting to print a new number each time a work order is printed…what happens if you want to reprint a work order, it would be given a different number, which is not true as it would just be a reprint.

You may also be able to use the Print Event of the detail section of the report…if you only wish to increment the number each time the report is printed, rather than run?

What do others think?

I’m not certain if I understand exactly what it is that you are trying to do? I assume that you just want a number on a report to be incremented by 1 each time you run or print the report?

You say that you do not need to keep the number is a table? I’m not sure what you mean by this, as the easiest way to remember what number you are up to each time is to store the number is a table.

I would use the Reports Open event to access a table and determine the next report value from that table and set a variable to hold the value. Then from the control on the report that I would want to display this number, I would reference a function which returns the current value of the variable.

Does this make any sense?

As an aside, at work we have an Acc 2000 database without any memo fields and it needs repairing on a regular basis (about monthly).

I suspect this high rate of failure is due to
(i) 3 data entry operators entering into database
(ii) resonably large database

The option to automatically compact on close is a good one – hadn’t even thought of this…isn’t it funny how sometimes the obivous answers are the ones that you miss

Thanks heaps Charlotte this should deal to the potential problem.

J

Dunno, thinking on my feet now

How about in the ‘corrupt’ database, create this code

Public Function DisplayCorruptForms ()
Dim frm as Form
Dim db as Database
On Error Resume Next
set db = CurrentDB
For each frm in db.Forms
docmd.openform frm.name
If err.number 0 Then
debug.print frm.name
err.number = 0
Else
DoCmd.Close acForm, frm.name
End If
Next frm
End Function

Run this function and it will display those forms names that can’t be opened in the immediate window.

No problem, it’s always fun to help others out. I only wish that I had a resource like this when I was starting to learn Access, it would have reduced many hours trying to decipher the MS Help files.

In fact, from memory it was actually a Report rather than a form…but same difference

I think what I had to do in the end was create an entirely new mdb then import all object apart from the one form that was corrupt.

I’ve seen form corruption in Acc 2K, where the form just wouldn’t open in form view, and when you tried to open it in design view, an error message ( I can’t remember what it was) just popped up and wouldn’t let me get at it. Had to start the form from stratch.

Sorry not much help, but I do have sympathy for you

I think that there are questions as to why users would or should be creating modules in an application??

If they are ‘power’ users creating modules for advanced functions on reporting, then perhaps you should be encouraging them to create modules in a reporting version of the database, rather than the ‘front-end’ application.

For users that create modules, what happens to their modules when you update the version of their database, their modules would be lost.

Another point is that most people distribute their applications as mde’s because they are compiled…which means that users can’t get in and change stuff in forms, modules etc AND Access runs an mde faster than and mdb so there are performance issues. Again this wouldn’t stop ‘power users’ wishing to report on the database from linking a seperate mdb that they ‘own’ and they could create modules until the cows come home.

I certainly try and make any applications that I write in Access work without the toolbars.

For search and filter options, usually it is only 1 or 2 fields that you ever want to ‘filter’ or rather ‘find’ on. I usually build this into the database via a nice big clear button and have code do what needs to be done in the background.

Admittedly, this creates a little bit of extra work, but I think is a nicer solution in the long run.

What does everyone else think?