I have an access databse (from an opensource project) that's in Access 2000 format.
All text fields, I've looked at, have ALLOWZEROLENGTH set to TRUE and DEFAULT to "" (empty string).
On conversion to Access 97 (using Access 2003) the ALLOWZEROLENGTH is set to FALSE but the DEFAULT stays at empty string.
Bizarrely (it seems to me) I can still add a record to a table without specifying values for many of the text fields without a problem.
However if I modify the table design by adding a field, thereafter if I try to add a record
lots of 'cannot contain zero length string' errors are triggered.
It's like the DEFAULT value properties on the text fields are dormant until then.
Is this a problem with the convertor in Access 2003?
I also tried converting first to 2003 and then back to 97 but the result was the same
Is the best action for me to do to go through the 97 database and set ALLOWZEROLENGTH to TRUE or set the DEFAULT to Null?
The "best action" is to not use the Access 97 database format. Office 97 is no longer actively supported by Microsoft; that has been the case for over nine (9) years now! (ref: here)
However, if you absolutely must use the Access 97 file format for some reason then yes, you probably should just go through the table definitions and adjust the field properties as required.
Related
I am using MFC to manage Microsoft Access databases usingCDatabase. I support both mdb and accdb formats.
My understanding of BIT fields is:
0 or Null is False or No
-1 is True or Yes
Is this always the case? Values of -1 and 0?
Thanks.
You've got one little mistake:
0 is False/No/Localized equivalent
-1 is True/Yes/Localized equivalent
Null cannot exist in a bit field, but will get displayed as an empty field, or an undefined value in a checkbox (filled with either a square or grey dots)
There should never be any other numbers
I am using Office 2003
On Access, I export values from a form into a .xls, after that using mail merge on word I import the data to be displayed on the file. Data such as dates and strings are displayed correctly.
In Access theres the value 9,916.12 wich is exported to the .xls as 'price' that contains 9,916.12, both values match keeping the same format, but when mail merge kicks in the value displayed on the document becomes 9916,1200000000008.
I am lost as to what is causing that. The field that is being exported contains only 2 decimals, it displays on excel as a value with only 2 decimals yet when word reads it, it adds random decimals to it. If I manually alter the value on excel the error persists, so does it if I choose a different record to be exported.
Any tips on how to solve the problem?
See this Microsoft Answers discussion and this in-depth description on how to use a merge field such as {Mergefield NumberFieldName \# ",0.00"} to work around the issue. It's been awhile since I had to do mail merges, especially with Word 2003, but I think that should do it.
An Access DB imports a fixed width text file; one column is mostly dates.
When the date is not available, the file's creator actually uses the string "Null"
Access puts the row in the table with that field actually null.
But, when the files started coming with different field widths, I copied the DB, tweaked the starting/width values in the input spec, and imported. NOW, all the rows with null get logging in (table)_import_errors as an error converting text to date.
I have found no setting (not that I changed any) to explain it. One difference is that although both DBs are in Access 2000 format, the original is on a machine that still has Access 2000, while the new one is being handled by Access 2003.
Is that a behavior change in the Access version? Is pre-processing the file the only solution?
Thanks, David. That's what I would have done (except for the Excel part) if it had not fixed itself. I posted that, but apparently someone didn't like the public admission that Access has bugs.
The only thing that changed was that two other columns in the fixed width plain text input was wider. Yet Access "decided" to discard the whole row instead of just the date field for three consecutive attempts. The fourth time, it still reported it as an error but imported the rest of the row.
So, when Access misbehaves for no good reason, try again a time or two, then try explicitly coding the conversion from text.
Two possibilities:
Use a buffer field or buffer table that imports the date field into a text field. Then you can process that into the appropriate values in the final destination field.
Use a SQL import instead of DoCmd.TransferText. What you do in that case is use a connect string in the FROM clause so you can then process the date field in your SELECT:
SELECT Sheet1.FirstField, Replace(Sheet2.DateField, "NULL", Null) As DateField
FROM Sheet1 IN 'C:\Import\Spreadsheet.xls'[Excel 5.0;HDR=YES;IMEX=1;];
Convert that into an INSERT query and you're golden.
I have a strange phenomen I can't explain nor reproduce and I'm hoping you have an idea how it was possible for the user to enter an invalid value.
I have an Access-MDB with a form containing an edit field that should only accept time values without any date-information.
The relevant properties of that edit field are as below:
bound to a Date/Time database value (since access know no time-only datatype)
Format: "Time, 24hrs"
Input Format: "99:99"
(I use the german version of Access, so the property names may be a little different, but you see the pattern)
Now I found out that a user was able to enter a date value into that field. I'm nearly 100% sure that it was an accident and no "clever hack" in the form of directly opening the table and editing the corresponding Date/Time field. Since the entry was made back in 2009 (nobody spotted the error), I have no chance to ask the user how it was done.
I found two wrong entries with the dates "01.06.2000" and "01.07.2000" and I guess the user wanted to enter the times "06:00" and "07:00".
I tried every input I can imagine (like "6.0", "6;0", "6,0", copy&paste) but I was unable to trick access and enter anything except digits and the colon.
Do you have any idea what is going on and how the user was able to enter these dates accidentially?
A Jet/ACE Date/Time value is never stored "without any date information". If you attempt to store only the time component, it will actually be stored with the same time on day zero (Dec 30, 1899).
We can only speculate how the incorrect data was added back in 2009. If you want the database engine to require your Date/Time values to be stored with day zero as the date component, you can add a table-level validation rule. From the table property sheet, try this for Validation Rule:
DateValue([your_date_field])=CDate("1899/12/30")
If you want to allow Null for your_date_field, try this version:
IsNull([your_date_field]) Or DateValue([your_date_field])=CDate("1899/12/30")
Several possibilities:
A developer (you?) did it by accident when looking at the raw table
The client Access software went momentarily crazy and corrupted the entry. This has happen to us (fortunately very rarely) where our Access tables will end up with non-ASCII characters in a string field.
A bug in Access runtime allowed the problem in the past, but has been corrected in a service pack.
Finally, if you put in 90 hours, does it overflow into 4 days and something? That might do it.
I have an Access file developed using Access 2003, and am trying to work with it using Access 2007.
Some tables have a "changedby" column, which has a default value of
=Environ("username")
This is triggering an error
Unknown function 'Environ' in validation expression or default value on market.changedby
Is there a replacement function available in Access 2007, which can be used as a formula in a default value for a column?
Check out this thread.
It's states that you have to wrap the environ call in a function to get around the Access "sandbox"
Another poster says you can set the macor security to low to fix it as well.