I have a table LABELS with columns CODE(short text), VALUE(short text) and DESCRIPTION(long text).
I also have a table LABELS_HISTORY with the same columns.
I created and After Delete macro on LABELS, which creates a new record in LABELS_HISTORY with the values of the deleted record from LABELS.
If I only use it for CODE and VALUE (which are short text), it works fine. But if i try to also copy the DESCRIPTION, it doesn't work (no error, just doesn't create a record in LABELS_HISTORY).
This is how the macro looks like: ( i can't embed images - newbie)
https://i.stack.imgur.com/igKlh.png
If you don't want to open the link:
Labels: After Delete:
Create a Record In LABELS_HISTORY
SetField
Name Description
Value = [Old].[CODE]
it works fine with fields that are short text. Only problem is with Long Text.
Access 2016
Long text values are not available through [Old].. There is no work-around as far as I know.
This does generate an error. In your USysApplicationLog table, an error should be logged, that has the following description:
The '[Old].[DESCRIPTION]' value is not available because the field is of type memo, rich text, hyperlink, or OLE Object.
(memo is the old name for Long Text fields, thus these are not available).
You can also see this behaviour in MS SQL Server, where previous values of fields of the type Text and NText are also not available in triggers.
A piece of advice: always log the Current value in your change tables, not the Previous one. That way, you always have a full history of every record, and you don't run into trouble with these things.
Related
Here's the crux of the question, I have 26 compliance queries to run, in a previous question it was suggested that I should filter a single query, or two, on a single report. I like this idea, and have rewritten the query to pull all available data from all the fields, this query works fine. The report will work fine as well, as it does with a model query that I had coded up beforehand. What I would like to do is this:
The end user is being given an interface in access that is locked down, I want them to click a button, and that button will run the query and send to the text box just the field that is called for.
I have tried doing this through VB using the where clause and aliasing the column being called, this did not work at all. I have the report currently pulling the correct data, but not displaying the dates along side it. But it is filtering correctly aside from that.
So what needs to happen is this : Button click : Query runs, and is filtered for "Compliance Issue 1" and puts the dates in "Compliance Issue 1" in the text box on the report.
Right now... I get a list of names, the correct list of names, but an empty column.
I have tried using OpenArgs, but all it did was fill in the date column with "Compliance Issue 1" not the actual data in that column.
Is what I am trying to do even possible in access, and if so does someone have a reference or suggested starting point.
My background : 6 Months of python coding, 3 months of SQL , and some limited access from 20 years ago.
As noted, using the filter of the openreport is without question the way to go (one would not write a whole bunch of different queries - you can send/have any filter for that report - you can EVEN use a sub query in the filter that you send to the report.
As for displaying values in the report that are not from "rows" of data?
There are two approaches that work quite well.
First up, is you have that launcher form. This of course allows the user to select critrea - maybe even some nice combob boxes. These selections take care and you build up the filter in code that you pass to the report.
As for text boxes to be filled out from that form and inclluded in the report?
If they are static values from the report (say filter options, or even just a notes box that you could type in some text? To display such values in textboxes on the report?
You can directly set the text box data source (in the designer) to the report propter form like this:
=(forms!MyPromptForm!notes)
So, any value you shove into text boxes on the report prompt form can thus be displayed in any text box on the report with the above type of expression. And it does not even take code to achieve this goal. So, you could say with above enter some notes into that text box, and thus on the report, whatever you typed into that text box will now show up in the report. You just drop in a text box onto the report, and set the data source of the text box to the above expression that references the form with the values we want from that form.
The next approach, and I often use this in the case that some value/expression/calculation has to occur for each row. In this case, you can use the reports on-detail format event. This allows you to run code for EACH row of data.
You are free to run ANY code in that event - and that includes after running such code to set a text box in the reports detail section.
So, say the query only had the Hotel ID (PK). This is a lame example, but you could then write this code in the on-format event of the reports detail section.
dim strSQL as string
dim rst as DAO.RecordSet
strSQL = "SELECT HotelName from tblHotels where ID = " & me.HotelID
set rst = CurrentDb.OpenRecordSet(strSQL)
me.HotelName = rst!HotelName
rst.Close
So in above, we assume that a row text box is called HotelID, and then in code we build a whole sql query from scratch, pulled the row data from a table, and then SHOVE/SET the value of the un-bound text box called hotelName.
As noted, the above is a simple example, but we are free to run any code we want, pull any data we want, and set the value of ANY text box for the given detail section ONE row of values.
So, above shows two approaches. The first approach is code free - and you can put forms! expression directly into the report, and the values from that report prompt form will thus show up directly in the report. However, if you need VBA code to run for each row, pull values, walk the dog, and THEN set a text box on that one details row of data, then you are as above shows free to write procedural code in the report that fires + runs for each row of data - and that means you can quite much do anything you want in terms of running code. I mean, even that on detail format event COULD pull values from your report prompt form, but as the 1st example shows, you can shove in forms! expression directly into a text box - and those forms! expressions can be values from a existing form that is open before the report is launched.
Working with a MS ACCESS 2010 accdb file. Within a table, on one particular record, I am experiencing something odd with a text field.
The text field is shown to be populated with Gzzzzzz. However, clicking on the fields [down arrow], [Text Filters], [Equals...] and pasting Gzzzzzz returns nothing. Then, clicking on the fields [down arrow], the shown field populations include GzzzzzzGzzzzzz: not, Gzzzzzz. Selecting GzzzzzzGzzzzzz a record is returned with the field populated with Gzzzzzz.
Showing all the fields again, and editing the field to Azzzzzz. Then, filtering on Azzzzzz again returns nothing. Then, filtering field options show AzzzzzzGzzzzzz: which when selected, returns Azzzzzz.
Also curious, when I filtered as above then look at the Property sheet, at this point the Filter shown is ([TableName].[FieldName] = "Azzzzzz ...missing the final "). However, when I filter on a working record, the Filter is shown as ([TableName].[FieldName] = "Whatever"): meaning shown completely with the trailing ").
The field is not indexed. There are no defaults or formatting. The table is related to three other tables: but, not on this field and not with Enforce Referential Integrity. Other records in the table are fine and work. Just this record's field.
Does anyone know how this happens? Is there a method to repair the record?
The field in the record probably contains
Gzzzzzz
Gzzzzzz
(with a newline in there) which isn't easily visible in a single-line textbox.
Use Shift+F2 to open the Zoom window. Or "tab" into the control, so everything is selected. Then delete the whole content and re-enter.
I have a field with a customer ID that should be in the format of C0000000001, where it has a letter at the start and up to 10 numbers after the letter with leading zeros between the letter and the number. I want the users to be able to put in C1 and have the table save C0000000001 or C1234 and have the table save C0000001234.
I want the restriction to be on the hard data in the table. The table should contain the full customer ID but I only want the users to have to enter the C and the number of the customer when entering/searching for customers. I am using Access 2010.
I believe that the first character will always be a C, but either way, it would only be one alpha character if it wasn't.
I understand what you are saying, but the majority of the data (thousands of records) are going to be from another system that stores them that way. Doing it this way limits my margin of error. Otherwise, exports from the other system will need to be manually changed prior to being imported into the database and vice versa.
Searching would only be on existing records that will be saved in the C0000001234 format, but I would like user to be able to omit the leading zeros when entering the search criteria.
This question, combined with your previous question here, suggest to me that you are trying very hard to have the data structure in your Access database exactly match the legacy system from which you receive bulk updates. That may not be necessary, or even desirable.
For example, instead of maintaining the CustomerId as Text(11) (as in the old system) you could store it in your Access database as
CustomerIdPrefix: Text(1), and
CustomerIdNumber: Long Integer or perhaps Decimal if the numeric part really can exceed 2,147,483,647
Your Customers table in Access could also include a calculated field named CustomerId as
[CustomerIdPrefix] & Right("0000000000" & [CustomerIdNumber], 10)
to give you a single 'C0000012345' value for display purposes.
For searching, your form could have a Text Box for the Prefix (default value: 'C') and another text box for the numeric part. The search could then use a condition like
[CustomerIdPrefix] = txtPrefix.Value AND [CustomerIdNumber] = txtNumber.Value
or, if the user wanted to create a Filter on the Form (or Datasheet View) it would probably be sufficient to just filter on the number part.
If you ever needed to feed information back to the legacy system you could just export a query that includes the [CustomerId] calculated field (and omits [CustomerIdPrefix] and [CustomerIdNumber]) and you'd be fine.
My suggestion would be to use forms with associated queries using the FORMAT function.
You do need to clarify where you want this implemented, but I'm going to assume you have a table set up and that you would like to be able to enter/search data from a form.
I'll create one form for input frmAdd. For the input form, I created a query that would run when a button on the form was pressed. Add two text boxes newID and newOther to the forms which are unbounded but which the user can use to enter data. The query will then pull that data and append it to your table in an altered format. Here's the SQL for that query:
INSERT INTO Customers ( [Customer ID], [Other Field] )
SELECT Left([Forms]![frmAdd]![newID].[value],1)
& Format(Right([Forms]![frmAdd]![newID].[value],Len([Forms]![frmAdd]![newID].[value])-1),"0000000000")
AS Expr1, Forms![frmAdd]!newOther AS Expr2
FROM Customers;
I'm not sure exactly what search functionality you're looking for, but this query would pull up the record data matching that of a frmSearch with a textbox search which would have the format C### or whatever entered in:
SELECT Left([Customers].[Customer ID],1) & Replace(LTrim(Replace(Right([Customers].[Customer ID],9),'0',' ')),' ','0')
AS Expr1, Customers.[Other Field]
FROM Customers
WHERE (((Customers.[Customer ID])=Left([Forms]![frmSearch]![search].[value],1)
& Format(Right([Forms]![frmSearch]![search].[value],Len([Forms]![frmSearch]![search].[value])-1),"0000000000")));
Applying the input mask is just a way to ensure that your data is correct. If you feel the need to use one, go to the table in Design View and click on the Data Type box for the customer ID field. Find Input Mask under Field Properties -> General and click it. Then hit go to the toolbar -> Design tab -> Builder. This will walk you through it.
Input mask is not the answer for this. Input mask forces the user to input the data in a certain manner. What you need is some VBA code to run in the AfterUpdate event on a form. There's no way within the table to force the data into this pattern allowing the input method that you've requested.
There may be a more efficient way to do this, but this does the job.
http://pineboxsolutions.com/access/customeriddemo.accdb
I have a report whose record source is a query, say qryRecords. In the report header I want to add a lengthy notes field (longer than 255 characters). I have set up a table to hold these notes (with a field type "memo"), and because that table is separate from the record source for the report, I was going to put the Notes field in the report using VBA code.
In the open event of the report, I have added this code:
Dim rst as Recordset
Dim sql_qry as String
sql_qry = "SELECT notes FROM tblNotes WHERE id = 1;"
Set rst = CurrentDb.OpenRecordset(sql_qry)
rst.MoveFirst
Me.txtNote = rst![notes] 'I get the run-time error on this line
Unfortunately I get a run-time error where noted ("You can't assign a value to this object"). I found a person with a similar issue on a form, and the suggestion was to move the code from the open event to the OnCurrent event, but that event doesn't exist for a report. Any suggestions? Thanks.
--- Original Question ---
I have a form with an unbound text box (txtNotes), and when the user opens the form, the text box is populated with text that is longer than 255 characters (it concatenates various fields from the database). This works with no problem.
There's a button on the form that opens a report, and in the report, I set the Control Source for a text box to Forms![frmMain]![frmSub]![txtNotes], which is the text box mentioned above. That works too, but for some reason the text on the report is truncated at 255 characters. The form's text box is unbound, so there's no underlying table to limit the length. Does anybody know why this would happen or if there's a workaround?
Most likely when the data from the field is being cast as a Text type rather than as a Memo. Really there's no way to explicitly cast a Text as a Memo (you can go the other way around though with CStr). I had problems with truncation on the form as well when experimenting with this scenario.
I'd suggest you are probably generating this field on the form in the wrong way. Dollars to doughnuts you could generate it in a query (used in the form's Control Source), rather than concatenating it together and placing into an unbound field. Likewise, you could then use that same query as the control source for the report that you are opening.
If all of that is truly impossible, I'd point you at dumping the values from the form into a table specifically for the report and then using the table as a control source for the report.
---- Edit ----
I still contend that you can add it to your Report's data source. In my example below, I've tacked on tblNotes to a select on the Bar table.
SELECT bar.f0, bar.f1, bar.f2, bar.f3, tblNotes.notes
FROM bar, tblNotes
WHERE tblNotes.id = 1;
Yes, if there is 300 rows of Bar, you'll get 300 copies of the same Notes field, but that's a minor problem.
Form there, you just make txtNote's data source the tblNotes.Notes column. txtNote can certainly exist in the report/page header, and when MS Access generates it, it will only use one row. I'm not sure if picks the first/last row, or random row - never the less since they are all the same, it doesn't matter.
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.