Using a query to supply an Access form - forms

I have a Microsoft Access form that is being supplied (somehow) by a query. The query contains three tables linked together via their respective primary and foreign keys, and the form displays data quite happily.
The strange thing (as far as I'm concerned) is the ability of the form to then allow data entry using the query.
However, if the user creates a new record, the whole thing seems to have problems due to a required field in the [table2] table.
SELECT [table1].*
,[table2].JobNo
,[table2].PlannedDateOC
,[table3].DateJobStarted
,[table1].PlanNo
FROM (
[table1] LEFT JOIN [table2] ON [table1].PlanNo = [table2].PlanNo
)
LEFT JOIN [table3] ON [table2].JobNo = [table3].JobNo
ORDER BY [table2].PlannedDateOC
,[table1].PlanNo;
According to the users, this form worked perfectly prior to conversion from Access 97/2003 format to Access 2010 (2007 file format).
Could anyone clarify whether this (the fact that it should work) is legitimate, and if this process would work in either version of Access, if so? The concept of being able to use a query for data entry is quite alien to me.
Let me know if you need further clarification.
NOTE:
One thing of note, here, is that I did move some of the fields into the form header so that they were always visible as the rest of the form scrolls. I don't know if this will have any side effects on the performance of the form.

Above query will allow you to insert data into [table1] when all not null fields have their values and make sure only table1.fields are getting dirty when new record is inserted.

Related

Can't remap fields - map fields window is missing new table

I have a Crystal Report with a database command:
The command has a join clause that can be removed and read from a table in the database, because it represents static data. I add this table (called _System) to the database expert:
Now I edit the command to remove the join and columns that reference this table. Since the report fields that depended on these columns are no longer mapped, this causes the Map Fields window to appear:
...which does not have the new table in it. If I cancel out of this I am back to where I originally was. If I hit OK without mapping, all of the unmapped fields on the report are deleted (suffice it to say... I was not expecting this >:( )
I have tried adding links between the command and the new table, and refreshing report parameters, but these have had no effect.
One workaround is to manually replace every field in the report, but this is very labour intensive.
Here is the outline of the command before:
SELECT ACT.Account_Code, ACT.Company, ACT.FName, --etc
STM.CompanyName AS 'DLRName', STM.Address_1 AS 'DLRAddress', STM.City AS 'DlrCity' --etc
FROM Accounts AS ACT
JOIN _System AS STM ON 1 = 1
GROUP BY ACT.Account_Code, ACT.Company, ACT.FName, --etc
STM.CompanyName, STM.Address_1, STM.City --etc
And after:
SELECT ACT.Account_Code, ACT.Company, ACT.FName, --etc
FROM Accounts AS ACT
GROUP BY ACT.Account_Code, ACT.Company, ACT.FName --etc
I have removed the JOIN on the _System table, and all referenced columns.
It appears to not be recognizing your _system table as a new source.
I would :
1) leave your command object SQL unchanged & get the issue worked out with the _System table, then
2) ensure that you are able to establish a join between the command object fields and the _System table fields, and lastly
3) then remap the fields.
Step two I suspect is the source of the problem, as your join condition is "ON 1 = 1" which I assume to mean that you may not have a common key field in both tables.
Note that your original command SQL selects STM.Companyname AS 'DLRName'.
Hence, crystal now know of a field called DLRName, but does not know of a field called CompanyName, hence it cannot make the association between DLRName in the old source, and CompanyName in the new source...
Likewise with the rest of the fields that are being moved from the command object to an attached table. if no name match exists...Crystal cant make the connection. However...it would list all unmatched fields that are on the report, and all unused fields in the recognized data sources, and allow you to specify the matches yourself.
But it does not...which tells me that something has gone wrong with the attempt to attach/open the _System table. Hence..you need to get that worked out first, then make the field adjustments.
If this doesnt get you thru...then show some sample data so I can see how the two tables are relating ( ensure some examples exists where there is a row match from both tables ).
I had the same problem a while ago.
Unfortunately I can't find anything online that helps, or maybe wasn't looking hard enough. I just noticed that in my case, that particular field that isn't showing in the map field dialogue box has nvarchar(max) as its datatype (in view).
I tried to force the datatype with CAST(missingfieldname as nvarchar(20)) as missingfieldname (I did this in the view), and voila, it magically appears in the map field dialogue box.
It seems that field mapping dialogue box aren't showing fields with blob texts.
I know this question was asked 4 years ago. But hopefully, this comment could help future solution seekers regarding this absurd and weird problem. I just got lucky seeing what's unique about that particular missing field.

Access Form won't accept input in text boxes

So I have a form in Access.![acessform1][1]
Here are form properties
I got this database and have been making adjustments to the other forms. I gave the database back to the user and they reported an issue that this form is not acting properly, and the add order record function is not working anymore.
There's an Add Order Record button on the right side of the form that would usually add the record if the user manually entered input into some of the boxes. The old form you would have control of the values 1/0 for yes/no. You can enter text into the notes boxes.
This functionality doesn't work anymore, and I can't seem to figure out why. The form is identical to the original and no adjustments have been made except to the table that it pulls data from.
So the symptoms are:
User input is not accepted in text boxes.
The find CP functionality works with the drop down and reflects the records accurately but I cannot update the fields.
Also, the fields CP_Ref and Invoice date don't let me enter data anymore.
Also the Add Order Record was giving me an error that The it could not find the record specified, but I since copied the original form back into place and that error went away.
I think functionality wise this button should save the record after a field is updated and should add a new record.
Seems like all the controls are locked on the page.
Here is the query that pulls the data when I click the button that takes me to the Order form.
SELECT DISTINCTROW CPOrders.Cust, Customer.NAME, CPOrders.CP_Ref, CPOrders.Slsman,
CPOrders.Date_opn, CPOrders.CPSmall, CPOrders.InvIssu, CPOrders.InvNo,
CPOrders.InvDate, CPOrders.DueDate, CPOrders.ETADate, CPOrders.Closed,
CPOrders.Cust, CPOrders.Name, CPOrders.BuyerRef, CPOrders.ToCity,
CPOrders.ToState, CPOrders.ToCtry, CPOrders.ToPort, CPOrders.Supplier,
CPOrders.Origin, CPOrders.Product, CPOrders.GradeType, CPOrders.NoUnits,
CPOrders.Pkg, CPOrders.Qty, CPOrders.TotSale, CPOrders.TotCost,
CPOrders.GrMargin, CPOrders.[Sale$/Unit], CPOrders.[Cost$/Unit],
CPOrders.OceanCost, CPOrders.OceanNotes, CPOrders.BLadingDate,
CPOrders.USAPort, CPOrders.FOBCost, CPOrders.FASExportVal,
CPOrders.InlandFrt, CPOrders.CommodCode, CPOrders.Notes,
CPOrders.ProjCust, CPOrders.ProjValue, CPOrders.ContainerNumber,
CPOrders.Vessel, Customer.TERMS
FROM Customer INNER JOIN CPOrders ON Customer.[CUST_#] = CPOrders.Cust
ORDER BY CPOrders.CP_Ref;
I ended up checking several locations for the answer to this.
What it ended up being was a primary key issue.
Essentially when I got the updated database I put them into new tables, effectively destroying the dependencies, relationships, and established keys.
I reverted back to the old tables and found out the form worked properly.
The issue ultimately was that the primary keys were not defined as needed for the table to be updated.

FileMaker Pro 12 Auto-populating Tables

I'm new to Filemaker and need some advice on auto-populating tables.
Part 1:
I have TableA which includes many records with client information. I want a separate TableB which is identical to TableA except that it is "de-identified"; that is, it does not contain two of the fields, first name and last name.
I would like the two tables to interact such that if I add a new record to TableA, that same record (sans first and last name) appear automatically in TableB.
Part 2:
In addition to the above functionality, I would also like said functionality to be dependent on a specific field type from TableA. For example, I enter a new record, which has a "status" field set to "active," into tableA. I then want that record to be auto-popualted into TableB; however, if I add another record with a "status" of "inactive," I want that that record auto-populated into a TableC but not into TableB.
FileMaker can perform this with script triggers so long as every layout where TableA will be edited has a layout script trigger of OnRecordCommit connected to it. When the record is committed (which can happen in a number of ways), the attached script will run, which you can use to create the appropriate record in the appropriate table.
The script could create the record in a number of ways. If the primary keys for both records are the same, you could use lookups. You could export the record in TableA and then import it into the correct table. You could pass the field information as a parameter to the script. The best choice really depends on your needs.
Having said that, I would question the wisdom of this approach. It brings up a few questions that would seem to complicate matters. For example, what happens when the status changes? When a record in TableA is deleted? When fields in TableA are modified? Each of these contingencies (and others) will require thought and more complicated scripts.
So I would ask what problem you're really trying to solve. My best guess is that you are trying to keep the name information private from certain users. User accounts and privileges with dedicated layouts for each privilege can solve this without the need for duplicate tables. FileMaker privilege sets can be quite granular.
For example, you can specify that users with PrivilegeA can create records and view names, but PrivilegeB users can only view records if the status is "active" and the name fields are not available to them, while PrivilegeC users can view records if the status is "inactive" and the name fields are also not available to them.
I would definitely use filters and permissions on the "status field" to achieve this and not two mirroring tables. Unless the inactive information is drastically different, you would be complicated your solution and creating more possible pitfalls.

Silverlight WCF RIA Service select from SQL View vs SQL Table

I have arrived at this dilemma via a tortuous and frustrating route, but I'll start with where I am right now. For information I'm using VS2010, Silverlight 5 and the latest versions of the Silverlight and RIA Toolkits, SDKs etc.
I have a view in my database (it's actually now an indexed view, but that has made no difference to the behaviour). For testing purposes (and that includes testing my sanity) I have duplicated the view as a Table (ie identical column names and definitions), and inserted all the view rows into the table. So if I SELECT * from the view or the table in Query Analyzer, I get identical results. So far so good.
I create an EDF model in my Silverlight Business Application web project, including all objects.
I create a Domain Service based on the model, and it creates ContextTypes and metadata for both the View and the Table, and associated Query objects.
If I populate a Silverlight ListBox in my Silverlight project via the Table Query, it returns all the data in the table.
If I populate the same ListBox via the View Query, it returns one row only, always the first row in the collection, however it is ordered. In fact, if I delve into the inner workings via the debugger, when it executes the ObjectContext Query in the service, it returns a result set of the correct number of rows, but all the rows are identical! If I order ascending I get n copies of the first row, descending I get n copies of the last row.
Can anyone put me out of my misery here, and tell me why the View doesn't work?
Ade
OK, well that was predictable - nearly every time I ask a question on a forum I stumble across the answer while I'm waiting for responses to flood in!
Despite having been through the metadata and model.designer files and made sure that all "view" and "table" class/method definitions etc were identical, it was still showing the exasperating difference in behaviour between view and table queries. So the problem just had to be caused by the database, right?
Sure enough, I hadn't noticed myself creating NOT NULL columns when I created the "identical" Table version of my view! Even though I was using a SELECT NEWID() to create a unique key column on the view, the database insisted that the ID column in the view was NULLABLE, and it was apparently this which was causing the problem.
To save some storage space I switched from using NEWID() to using ROW_NUMBER() to create my key column, but still had the "NULLABLE" property problem. SO I then changed it to
SELECT ISNULL(ROW_NUMBER() (OVER...) , -1)
for the ID column, and at last the column in the view was created NOT NULL! Even though neither NEWID() nor ROW_NUMBER() can ever generate NULL output, it seems you have to hold SQL Server's hand and reassure it by using the ISNULL operator before it will believe itself.
Having done this, deleted/recreated my model and service files, everything burst into glorious technicolour life without any manual additions of [Key()] properties or anything else. The problem had been with the database all along, and NOT with the Model/Service/Metadata definitions.
Hope this saves someone some time. Now all I need to do is work out why the original stored procedure method I started with two days ago doesn't work - but at least I now have a hint!
Ade

coldfusion - bind a form to the database

I have a large table which inserts data into the database. The problem is when the user edits the table I have to:
run the query
use lots of lines like value="<cfoutput>getData.firstname#</cfoutput> in the input boxes.
Is there a way to bind the form input boxes to the database via a cfc or cfm file?
Many Thanks,
R
Query objects include the columnList, which is a comma-delimited list of returned columns.
If security and readability aren't an issue, you can always loop over this. However, it basically removes your opportunity to do things like locking certain columns, reduces your ability to do any validation, and means you either just label the form boxes with the column names or you find a way to store labels for each column.
You can then do an insert/update/whatever with them.
I don't recommend this, as it would be nearly impossible to secure, but it might get you where you are going.
If you are using CF 9 you can use the ORM (Object Relation Management) functionality (via CFCs)
as described in this online chapter
https://www.packtpub.com/sites/default/files/0249-chapter-4-ORM-Database-Interaction.pdf
(starting on page 6 of the pdf)
Take a look at <cfgrid>, it will be the easiest if you're editing table and it can fire 1 update per row.
For security against XSS, you should use <input value="#xmlFormat(getData.firstname)#">, minimize # of <cfoutput> tags. XmlFormat() not needed if you use <cfinput>.
If you are looking for an easy way to not have to specify all the column names in the insert query cfinsert will try to map all the form names you submit to the database column names.
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7c78.html
This is indeed a very good question. I have no doubt that the answers given so far are helpful. I was faced with the same problem, only my table does not have that many fields though.
Per the docs EntityNew() the syntax shows that you can include the data when instantiating the object:
artistObj = entityNew("Artists",{FirstName="Tom",LastName="Ron"});
instead of having to instantiate and then add the data field by field. In my case all I had to do is:
artistObj = entityNew( "Artists", FORM );
EntitySave( artistObj );
ORMFlush();
NOTE
It does appear from your question that you may be running insert or update queries. When using ORM you do not need to do that. But I may be mistaken.