I want to create a table for experiments results that are save in excel sheet. I want a main table that each row represents an experiment (with the columns: Test Name, Date, Conductors, Description) and sub tables with each experiment results. I want to connect them so when I choose a row from the main table I will see the sub table with the experiment results. Is there a way to do this in SSIS?
I tries looking up how to create a parent child connection but I didn't find something that does exactly what I'm looking for
Related
I have an old dbase-database (made with a program programmed with clipper 5.2) which consists of multiple tables (files). The tables are linked with some sort of recordnumber, but in the source table, no recordnumber-field is found. I want to convert this database to Access and re-establish the links. I've read something about a dbf recordpointer (?) but i don't know how to extract it from the DBF.
Well, if recno() or some such is being used, then it suggests that the table starts at one.
Remember, you can’t update a PK autonumber in Access, BUT YOU CAN RUN append queries against such tables!!!
So link to a dBase table. When you view this table in Access does it show that incrementing column?
It should and does for me.
The above detail has not been made clear by you.
So let’s assume you see this column that increments and is NOT marked as a PK?
That is just fine (and is expected). As LONG as you see the incrementing number in that linked table then you are just fine.
This process of importing then becomes rather fast and easy.
On the create ribbon tab, just choose query design.
Drop in that linked table.
From ribbon choose make table. Enter your new local table name.
Drag the * from the table into the into the query grid (first column of grid).
You have this:
Now run the above query query (hit the run button in ribbon).
Exit (toss that query out – no need to save).
The result will be a new local table, with that number column.
Now, empty data from that local table.
(Ctrl-g to debug window)
Currentdb.execute "delete * from NewLocalTable"
Now do a compact + repair (this re-sets any autonumber columns in empty tables – might not be required – but just do it anyway). And it reclaims the empty space for that table we just emptied out.
Ok, now open that new local table in design mode. Select that first number id column, and delete it. (click on that row - likely first row - hit del key).
Now, click on first row to select the column that is first. Hit insert key to push it all down, and enter the name of the numbering column you JUST deleted. Tab key, autonumber, and then from ribbon whack the PK button (primary key button).
Close table designer. Save the design changes.
We now have an empty table with a PK autonumber column as the SAME name as what we had before.
Now, create new query, droop in linked table.
From ribbon choose append query, and enter name of new local empty table.
Drag the * into the query grid.
Run it.
We now have a local table, with PK autonumber, and the columns will match up to the linked table.
For a 10 second test?
Ctrl-g (jump to debug window).
Type in:
? dcount("*","linkeddBaseTabble name")
? dcount("*","NewlocalTable name")
The record counts should be the same.
At this point you have a local table with same columns + the PK ID autonumber column.
You can repeat the above over and over. It goes fast. 20-30 tables will not take long.
The result is now local tables, and each table will have an autonumber PK column with the same column name.
I would think the column as a linked table is “ID”, but it might be RECNO. (So use that for the local PK column names).
So you:
Link to dbase table.
Query builder – make table.
Ctrl-g to empty local table:
Currentdb.execute "delete * from local table name"
Open local table in desing - delete number column, add it back as PK autonumber.
Query builder, drop in linked table. From ribbon select append query, enter name of local table.
Drag “*” to query grid – run it.
You now have a local table, with PK autonumber same as linked table.
Move on to next table to import (add an autonumber to each table you import with above few steps.
You could just import the tables in Access...and work your way using them as blueprint.
Just ensure that the "table relations" are correct... i know that there isn't one but take the "logical" path...if you a table with a fieldName "FaxBookID" and you have a table "FaxBook" ...you know they are related
I posted a couple times over the last couple of days about some trouble I'm having with an inventory database that I'm trying to make at work. I have very little experience, so have been mostly following YouTube tutorials and walk throughs online.
Essentially I have a table that will be filled with inventory information such as ID number, manufacturer, model number, etc. I then have a form that has a text box for each field in the table that the user will fill in and then an Add, Delete and Edit button that will allow them to either Add a new record by filling in the text boxes and clicking Add or select a current record in the table from a combo box or list and edit it or delete it by clicking the associated buttons.
I tried to code this first and kept getting an error for the past two days no matter how much I tried to fix it and what advice I got on here, so now I'm at the point where I'm just using queries to do it.
Right now I have a main table, temp table, the form, and then these queries:
1. delete query that will clear the temp table
2. append query that will take the records from my temp table and add them to my main table
3. append query that will take the selected record on form and add it to the temp table
4. update query that will update the fields on the main table to the data in the temp one
5. delete query that will delete the record you select on the main form from the main table
This was my plan:
for adding a new record
1. run query no.1
2. load the form
3. if OK button clicked:
4. run query no.2
for editing
1. run query no.1
2. run query no.3
2. load the form
3. if OK button clicked:
4. run query no.4
for deleting:
1. load a msgbox with the YesNo options
2. if Yes button clicked:
3. run query no.5
The one I'm having trouble with is query number 3. I've made the query correctly to the best of my knowledge, but when I fill out the form and click add it tells me the query is going to append 0 rows and then it doesn't add anything to the temp table.
I also can't seem to figure out how to take the data from the temp table and move it to the main table using the query.
I'm linking to an IMGUR post with screenshots in it here:
http://imgur.com/a/ffWge
Any ideas?
I hesitate to answer this since there are too many points to cover. Gustav already gave great advise about learning to use Access Forms like they are intended. But from the screenshots, it looks like you misunderstand something fundamental about the Access query designer. Even though you shouldn't have to write any queries for want you want to do, at some point you will need to understand how to properly design a query.
If you want the query to insert FROM the form INTO the table, then the table field references should not be in the criteria, they should be like this:
Field: [Forms]![frmInventory]![ICN]
Table: {leave blank}
Append To: ICN
Criteria: {leave blank}
Also, remove [tblInventoryTemp] from the query window since you already specified the destination table in the Append Query pop-up window. The SQL should look something like this:
INSERT INTO tblInventoryTemp ( ICN, model, serial, ... )
SELECT [Forms]![tblInventory]![ICN], [Forms]![tblInventory]![model], [Forms]![tblInventory]![serial], ...
Likewise for the other query to copy from temp to the main table. You should have already specified the destination table in the pop-up window, so remove [tblInventory] from the query window. Also remove the list of fields you have in the Criteria row. The SQL should look something like this:
INSERT INTO tblInventory ( manu, model, serial, ... )
SELECT tblInventoryTemp.manu, tblInventoryTemp.model, tblInventoryTemp.serial, ...
FROM tblInventoryTemp
Access will likely add more details, but the general form of the SQL should match what I have.
Hi I have a table that is simply a copy of another table on another sheet on my workbook.
The second table is generated using
DATA -> Existing Connections-> and then I select the Table tab.
Usually this work really well but in some cases (not always) the new table has the rows in a different order from the original one. How is it possible to avoid this?
I have a series of tables in an Access 2007 database. I am trying to find a way of outputting a flat-file to an excel spreadsheet that combines all of the tables so that each row of the flatfile represents a unique combination of the table rows from each table.
For example, these tables:
Would combine to make this output table:
The challenges I'm facing are:
The 'input' tables can vary in number of rows and columns, as well as quantity
The total number of rows in the final output table can get quite large (200,000+ rows)
I know Excel and VBA (in Excel) well but almost nothing about Access
Is there a way to do this in Access? Is there some native functionality in Access that I'm completely overlooking? Any pointers (even if it's "you need to read into X and Y") would be greatly appreciated!
Thanks,
Adam
As noted above:
Create a new query. Select your 3 tables as the data sources. If desired, set up joins between tables by dragging a line between a field in one table to a field in another. Without joins you will get a Cartesian Product ... every from 1st table paired with every row of 2nd table, and then each of those combination paired with every row of 3rd table. Select the fields you want included in the result set. When the query returns what you need, save it and give it a name. Then you can export that named query to Excel.
If the table is large, you could hit Excel's row / column limit though.
I work with a product that comes in a 2000lb sack and placed on a pallet. When this product is made it has many different elements that are tested and each test has a field that the numerical data is placed in. Each of these records of tests are then assign a number, for example, L20444.
Now we have the ability to take that 2000lb sack and convert it into 80 20lb bags. Only 40 20lb bags can fit on one pallet, taking now the one pallet L20444 and making two pallets that have the number L20444. This causes a problem with inventory because the number L20444 can only be assign one warehouse location, not two.
So my bosses what to create a number that is almost the same, but different enough to place the second pallet in the warehouse. The second pallet will now be L20444B. It will still have all the same tested numbers and is a "copy" of the original L20444.
My question is can I take the record L20444 and copy all the data for that record and then save it as L20444B so that it can be placed in the warehouse.
So is it possible for VBA to copy a record, rename it, and then save it in the same database as a new record?
Any help would be appreciated, Thanks.
If I'm reading you right it sounds like you want a SQL statement to create a new record.
You're using Microsoft Access? I would recommend first creating a query that does this in the query editor. It will be an Append query, something along the lines of:
INSERT INTO TableA ( ID,col1, col2 )
SELECT [ID] & "B" AS NewName,col1, col2
FROM TableA
WHERE (([ID]="L20444"));
Test this first to make sure it's doing what you want, and make "L20444" into a parameter ([OldID], or something). Then add some code in your VBA script that executes this query. It should pop up asking you for OldID when you run it.
Then you'll need to learn how to execute parameterized queries from VBA.
Something like this:
Set qdf1 = CurrentDb.QueryDefs("myQuery")
qdf1.Parameters("OldID") = theOldID
qdf1.Execute
Not tested, search VBA help for QueryDefs if my syntax isn't quite right.
Why don't you create a new table, which tracks the location of the two pallets (and the new number(s)), which links back (with a foreign key) to the single record for the stock in the original table?
That should work, and will avoid what will otherwise become a nightmare of redundant data.