Search results

You can have conditional compiler directives something like this below (Offhand aircode) Others will know the precise syntax. The code will work correctly at run time, and resolve the bitness. The trouble is that you can't build this into an mde/accde and have it work in both bitnesses, as it...

If you do that you are back to the same issue. It's hard to develop new facilities as you are always working on the live database. If you split it you can develop using a test version of the database with a test version of the data. When the work is completed, you can release the test version...

If you use mdbs it's a lot easier. You can build with conditional options to select code that is compatible with A32 or A64 and have that resolved at run time. That won't compile to an mde, but it does mean you can have a single database that will work with both versions of access.

Seriously, I don't see how you can need over 1000 forms.

My recommendation is to understand the full scope of the project, and to get the data analysis correct, so the table design stands the test of time. Everything else flows from that. Edit. There is no real reason for a project to grow out of control. If you are adding lots of forms each month...

With this sort of thing, it's good if you can get a standard storage mechanism. Instead of using the parentheses, give the values a separate comma separator. So you get 2, part number 1, 6, part number 2, 8, part number 3 This way it probably becomes easier to process. You have to realise...

Office used to install as 32bit by default, but it's changed to installing as 64bit. You could reinstall as 32bit, and see if that fixes the FoxPro issue, but it does beg the question as to how your other databases are being used. If they are compiled to accde versions, then users might not be...

@Misionero What you will find is having lots of child tables can make database development awkward, and can affect performance in some ways. It makes a lot more sense now you explained what the DNI actually is. So one way is to have a person, and store the DNI details in the person table...

@GaP42 An interesting discussion on the peculiar nature that a "simple" address can become in certain cases. Out of interest where do old passwords get stored. Is there a long encrypted string of them all somewhere? It has to be stored somewhere, and it's really representative of a 1:N...

@Misionero Your original.premise is wrong. It's wrong to say a person can have just one document. A document might belong to one person, but a person can definitely have more than one document. In point of fact a document can have more than one owner. A deed for a property can have multiple...

A person table linked to an identification document is 1 to many. Let's say you store a passport document. Now if you replace the passport you can store both the original passport and the new passport. You may need the old passport reference. It's not changed from 1:1 to 1:many. It's always...

Well then you are ok to enter more, aren't you?

I wouldn't worry about a user entering 21 items. Could you check on starting whether the table is now "full", ie >=20 items, and don't let them add new ones at that point.

I don't know if this is the same. I have strings to be processed, and include replace tags surrounded by curly braces. {Employee_name} I explicitly check for all pre-defined tags and replace them as appropriate. Is that relevant for what you are doing?

It would be interesting to know what fields you have. Given that a payslip once produced would never be altered I would be inclined to include some cumulative values in the payslip record, such as "total tax paid in this employment",which is re-evaluated as you produce each pay slip. It's a...

If they are many to many (i assume that is what is meant by N:M, then that cannot be represented in a relational database, and has to be replaced with a junction table, to yield 2 x 1:N relationships. For example, a customer cannot be directly related to ordered items. You have to include a...

I doubt it's crackable, especially as you have such a small amount of encrypted data. When you created an mdw file, access/ms did give careful and explicit warnings regarding the password, and it's security. Perhaps you weren't involved personally at the time. You might try...

I assumed it was me just not understanding, but maybe not.

If you do it the other way. ... Find items with no difference, then everything else is a difference.

Don't forget that Access makes lots of things very easy. Data binding, data updates, continuous forms. It will be enormously difficult to programme that all in. I keep trying it out, and the data binding/continuous forms stuff just seems so difficult to achieve. If I could get that working, I...