Forum Discussion
AustinK
6 years agoQrew Commander
If the Employee field is a lookup field down to transactions then importing by name is probably not going to work. What type of field is the key field in this relationship? Numeric reference? If so you would need to import the Employees into the transaction table by their record id in the Employee table.
If your list of transactions only has employee name then you are going to have to use excel and do a vlookup to match name to the record id from the Employee table.
If your key field is not numeric then post back with what it is or if you have any questions let me know.
If your list of transactions only has employee name then you are going to have to use excel and do a vlookup to match name to the record id from the Employee table.
If your key field is not numeric then post back with what it is or if you have any questions let me know.
- LoganLott16 years agoQrew Member
I had originally had it Numerical then changed into to user key field. I was hoping the vlookup was not something I would have to resort to outside QuickBase.
But now that I think of it, would it be better off to upload this data through the employee table instead?
Thank you for the quick response.
------------------------------
Logan Lott
------------------------------- AustinK6 years agoQrew CommanderUser is different than Employee Name. A QuickBase user is like <dfkg.j5645> so the name will not apply there either. I know it is frustrating to deal with all these different types.
As I understand it these are transactions, right? So you still want to import to the Transaction table. I prefer going by record id and having that be the key field. It makes a lot more sense than user because the user can be annoying to find for each and every record in cases like this.
I am not a fan of vlookup either but I think it might be your best option here. Do you not have any unique identifier in the excel sheet other than employee name?