Many records and few fields? A table layout should do the trick. That is, a table or grid with edit-in-place controls. That would support viewing, adding, deleting, modifying, filtering (querying), sorting, and comparing your database records. This works as long as the database records have few unshared fields (you can disable or hide the fields that don't apply for a given record). A table layout pretty much covers everything users can do. Is there anything else to the users' tasks?
There are only two other alternatives for basic record-and-field database data:
"Page layout," where each database record appears as a single form and (optionally) the user can page to other records with command buttons. That's best when you have few records to view at a time (e.g., after querying), but a large number of fields.
"Graphic layout," where the position of record data on the screen represents similarity among the records (typically on one or more record fields). An example is showing appointment records in a calendar. That's best for the user looking for relations among the data.
Beyond that, database UI design involves combining the three types to exploit the strengths of each. For example, depending on the users tasks, you may want show different types of data (e.g., from different database tables) in a different windows (e.g., serial code data in one window, password in another). Or maybe secondary detailed data may be shown in an overflow pane from the main records (e.g., show the ID, name, and type in a table, and everything else in the overflow, which populates when the user selects a record in the table; hide and show relevant fields in the overflow as necessary).