Hi @cs3e ,
“dbo” is an acronym for DataBase Owner. In some cases it is necessary to identify the objects by their owner name. By default if the current owner of the database creates objects inside of it, those objects would be recognized/qualified by their owner name.
insert into dbo.InvoiceHeader(invoice_number, invoice_date, invoice_amount,...)
select 123, 10/05/2021, 3456.78...
In my post yesterday, I was trying to articulate how your Insert query might look like in your Access Database. Here is an example from a standard MS Access Sample database.
To follow Steps 1 through 3:
- Right-click on Contacts Insert Query and select Design View
- When Design View opens up, select the SQL View from the View drop-down on the Top-left
- The Design will open up in bare-bones SQL view
From this you can ascertain how an Insert Query is modeled in MS Access.
With this information you can build your Insert SQL and save it as a named Query that you can then call from RPA and pass this query the inputs .
Imho, regardless of the scale of your database (MS Access or anything larger) a good way to separate RPA from the database is to keep things where they work best.
If you put in a raw INSERT SQL query in the Automation, you are tightly binding the Robot with your database which is not a good approach. This can lead to situations where you have to modify and redeploy your Robot each time you want to change something in the SQL.
Instead if you put contain everything within a canned Query on the Access side, your Robot does not have to change as long as the name of the Query and the I/O parameters you pass to it remain unchanged.
It’s a good practice to keep these considerations in mind as you build and enhance your applications.