Will calculate the fiscal quarter of the given date (Now() in this case). However, there is no native function (that I know of) for calculating the week/month within the fiscal quarter. I would assume you will end up needing to code a function that will recognize which week/month of the year you are dealing with, and then assign it a fiscal week/month value.
Correct me if I´m wrong, but looking at what you have I assume you have one subject; Downloads, with various characteristics : Ready, Flagged_To_Star t, etc.
That would mean one table called Downloads, with a primary key column and four boolean columns.
Each Download instance gets a separate record that records the boolean values of each characteristic (or Date-Time if you are intending this to be a logging table)....
Excuse me, You actually have a Many to Many relationship between Artifacts and Attributes. However, even with this, it really only requires three tables...
I fail to see the reason for one table for each attribute.
Given Artifact A: It can have many Attributes. That means One to Many, therefore needing only two tables... Am I not understanding something vital to your situation that makes one table for each attribute necessary?
Two tables would be far below this index limit, right?
[CODE=sql]PARAMETERS Branches Text ( 255 );
SELECT Table1.Branch
FROM Table1
WHERE Table1.Branch=I If(IsNull(Forms !Form1.Text0.Te xt),[Branches],Forms!Form1.Te xt0.Text);
[/CODE]
As I see it, the main problem is being able to use one criteria OR the other criteria as your parameter. If the form is open, the query needs to know to use it and not ask for the other, however, if the form is closed it needs to...
I'm sorry, I should have explained that one a little better.
Code:
Forms![Form Name].[Control Name]
OR
Code:
Forms![Form Name].[Property]
is the correct syntax when referring to a form from outside of it's form module.
I suspect this isn't going to be helpful to you in this particular instance, since if I understand you correctly, you are attempting to write the form name to a global variable to be used later in your code processing....
How do you know that John Doe is one person rather than three people with the same name?
When you answer this, remember that YOU may know, but how does the database know? At this point you have listed three identical names, with different addresses and different email addresses and different comments.
Any solution to your question is going to have to first of all answer this! Otherwise you will have a total mess with...
You did the decompile on the front-end db where the code resides, right?
There are a number of reasons for poor performance in a database, not least of which is un-optimized code and queries.
However, in this case I suspect it's not because of this, but rather could be a potential network issue. Things as innocent seeming as the RPM speed of the hard disk on the server (where the back-end .mde file resides) can affect...
An input mask exists to restrict and focus the data entry. It exists for data validation. I agree with ADezii. Giving the users the ability to change this on the fly negates the primary purpose for which it exists in the first place!
I would need a very compelling reason before being able to suggest that this is a good idea :-)
FYI when in the VBA editor window, position the cursor within any word and press F1 to bring up the specific help topic for that word... You probably know this already, but just in case.
If it's an mdb file the GUI (graphical user interface) part was created in Access.
Knowing what you mention to me now, I suspect you have a two section database, also known as 'front-end' and 'back-end'. The 'front-end' is the GUI part and contains the forms, queries, reports, etc that the user sees. The 'back-end' holds the tables and data. The back-end could easily have been created in Oracle.
You could try the decompile command line method. Many people have reported significant (up to 50%) size reductions and speed improvements when doing so.
On a backup copy of the database. Compact/Repair, close the database. Call up the command prompt (Start Menu>Run) and type in something like this:
"C:\Microso ft Office 2003\OFFICE11\M SACCESS.EXE" /decompile "C:\Documen ts and Settings\Scott\ Desktop\EMHS.md b"...
As an alternative to using the Erl function you could simply create a variable tuned to hold a line number within the current procedure, then refer to this variable in the Procofline() property, this is a little more suspect, though, as any changes in the code (i.e. adding a procedure above) could potentially invalidate this variable.
A potential solution would involve setting all your control's visible property to False, then using the Me.Print method in the reports' detail section to print the text directly to the underlying report. I have used this myself, and it is quite flexible (haven't figured out how to change the text to vertical, though, but haven't tried either :-).
Leave a comment: