But I read in one site ..that the unBound Form is necessary For safe when we are use ODBC
Please post a link to the article so we can rebut it. Sounds like it was written by someone who doesn't know how Access works or even what it is. Most of the articles that pan "Access" are not actually referring to Access at all, they are panning Jet/ACE which are the database engines that Access uses to store its own objects.
Almost all my applications use an ODBC BE - SQL Server, Oracle, DB2, Sybase, and a couple of others -- whatever the client is using for his other applications, I use for his Access applications to keep his operation simple. I always develop with the intention of converting even if I neve have to so for my apps, I can convert them in less than an hour when the time comes.
Access is tightly integrated with Jet (.mdb)/ ACE (.accdb) and so you can do almost anything and get away with it. However when your forms are bound to ODBC databases, they need to be bound to queries rather than tables and the queries need criteria to limit the rows returned. Access forms are typically bound to tables and filtering is used to get the user to the record he is interested in. The object when the BE is ODBC is to get the server to do the heavy lifting so you never bring down an unfiltered recordset to filter locally, you always use criteria so the server returns only the record you want. This can be done by creating forms that offer multiple filters if you want to have a lot of options or if you only have one or two, you can add unbound combos or textboxes to the form's header and use those for filtering.
The important thing about bound forms regardless of whether the BE is Jet/ACE or ODBC is to have an understanding of how form events give you control over whether records get updated. The most important form level event is BeforeUpdate. Think of it as the flapper at the bottom of a funnel. If the flapper is open, the record gets saved. If it is closed, the record does not get saved. There is NO way to avoid this event. It ALWAYS runs whether you or Access decides to save a record and it can NEVER be bypassed. Only people who don't understand this event can't control whether or not bad data gets saved.