Hi Hendra,
that's a deceptively complex question you have there...
Access does an amazingly good job of creating it's own CRUD/SELECT/INSERT/DELETE/UPDATE SQL Commands based on its knowledge of the things on/in your forms/recordsets and the SQL Server behind them. I typically find that making Access use Stored Procedures to do standard operations like SELECT, UPDATE, oder DELETE is more effort on the SQL side than it is worth. My one *major* exception to this would be if you have specific user rights issues which are (my opinion) going to be easier to handle on the SQL Server side than in Access.
The answer for you will depend on several factors, how comfortable you are letting Access make decisions for you, how comfortable you are generating and maintaining the multiple Stroed Procedures you are going to need to cover the most important (or all) eventualitites, and how comfortable your SQL DB Administrators are with the loads on your servers and the techniques used.
There is no single "right" answer, quite often not even in a specific environment, so the solution is going to be best served either with a mixed set of methods or, a rigid adherence to standards that you define together with your DB Administrators.
Yours,
Andrew
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (5) |
Tidak ada komentar:
Posting Komentar