Begginer! please help.

FeelCore

New member
Local time
Today, 19:51
Joined
Aug 20, 2025
Messages
9
as beginner, I have created this database for my work. its very small but... Can some expert check if there isn't some major problem, which i can have if i make it as template and set up in my work ms access?
 

Attachments

As a beginner you first need to tell us about the business context - what is the database for, how you expect to use it in your work. The start and fundamentals for your database are to understand the scope and business requirements to then define a database schema on which you can build the application. As it is written using a language that is not English - it is difficult to interpret. If your tables are well-formed, you are not enforcing referential integrity in any of the relationships. That is about the rules that determine such things as what record must exist before a record in a child table can be added, or when deleting a record do you want the child records to also be deleted, or will they be orphaned. Cannot tell if valid but KOMB_ID in KombiT relates correctly to Vakcin_veids. But difficult to move further without more explanation of your business.

Language" Latvian, seems to be about vaccinations?

EDIT:
Also: At the top of EVERY VBA code module enter
Option Compare Database
Option Explicit

The compile the code - it will show coding/syntax errors that you can then fix. To set it as a default, in the VB editor, under tools select Options and the Editor tab in the dialog. Make sure Require Variable Declaration is selected. This does not fix existing code, you have to do that by hand.
 
Last edited:
As a beginner you first need to tell us about the business context - what is the database for, how you expect to use it in your work. The start and fundamentals for your database are to understand the scope and business requirements to then define a database schema on which you can build the application. As it is written using a language that is not English - it is difficult to interpret. If your tables are well-formed, you are not enforcing referential integrity in any of the relationships. That is about the rules that determine such things as what record must exist before a record in a child table can be added, or when deleting a record do you want the child records to also be deleted, or will they be orphaned. Cannot tell if valid but KOMB_ID in KombiT relates correctly to Vakcin_veids. But difficult to move further without more explanation of your business.

Language" Latvian, seems to be about vaccinations?
Thank you for your time and advice!

I will try to explain so everyone could understand better. Language is used Latvian but no apostrophes used in names as VBA, table names an such on.
this is small business - vet clinic.
database purpose is to collect data about simple things as - client info, visits, vaccinations and some medications used in visits. some forms just show aftermath about vaccinations and medicine so i can faster fill some forms in real life.
PamatsF is main form. there you can go to clients card (klienta kartinas) and after that to visit card where is smal subform with history, and main subform to fill visits card. and main visits form is basicly clients small info (usefull at work, so i dont have to go back to clients card to see info)
Other btns in PamatsF is more for aftermath and overall view whats have happened about vaccinations, medicine and so and so..

About Komb_id (eng would be Combo_ID and KombiT (eng would be - ComboT)
Idea, was and is, to create combo box in Vaccination table (Vakcinacija_tab), where i can select different vaccination type where these types, after all, can count with what kind of ilnesses and how much animals i have done. that is why there is little bit circus in my opinion but i couldnt think other idea how to get what i needed.
and it is what is is, because some vaccinations have that ilness covered in and some dont, so if you look in KombiT you will see simple table with true or false statemant fields. where it mark it for every new vaccination type so that databse in end can tell how much that ilness i have covered!

About enforcing referential integrity.
its little bit on purpose. there cannot be any deletions at all. only some data change is there if something incorrect with client data. but if mistake was made and deleted client, i will still see some data with used medications but there will be #deleted shown and i will know. ( in forms there are no options to delete client or records. ) and still, if this client is taken out (IDK WHY) but medications was used and they have to stay for aftermath.

i hope i have explained about basics
if there is any questions, i'm happy to answer and i will be glad for any advice on this thing!
 
I am sorry if my English is not on peak level, but i understand very well what everyone says and i hope my level is enough to understand me in the end ! ;)
 
No need to apologize - you are doing well. If I can just review some things you have said:
database purpose is to collect data about simple things as - client info, visits, vaccinations and some medications used in visits. some forms just show aftermath about vaccinations and medicine
For a veterinary clinic. - 1 only
Your clients (in the client table) I presume are people, but as a vet clinic it is the animals that are treated - so perhaps you need a separate table for Clients and Animals (a Client can have multiple Animals). A Visit occurs when a client brings an Animal to the clinic - no offsite visits? Do you want to allow for this or perhaps later another clinic? At a Visit, one or more treatments are applied (instanced through a TxApplied table) which identifies each Treatment (type) - it may be medication, vaccination, some other procedure, or investigation to diagnose or treat the animal (if it can be generalised to this level). The animal then may have one or more Conditions as diagnosed through TxApplied.

Initial thoughts - preliminary schema - that you might consider how it corresponds to yours:
1755779775944.png


Depending on generalisations Procedure/ Medication / Vax might able to be combined into Treatment, designated as types. and VaxApplied to TxApplied. It is difficult to comment on the attributes you have assigned to your tables. The process to review and assign these attributes is called database normalisation. A fully specified vet clinic schema would appear much more complex than above however I assume you are trying to keep it simple.

You do need to apply referential integrity constraints in your schema.
Not sure if you mean Aftermath - as the consequence of an action - or Outcomes - as the result or effect of a treatment.

Re deletions - whether normal use permits them or not, you will need to set the constraints up so that say a client record cannot be deleted in visit records exist for the client. Records can be effectively hidden and not deleted by using an IsArchived flag (on the client record for eg when they are no longer a client or on an animal record if the animal has died. The data can still be accessed for reporting but may not be visible for entry of data.
 
Before you build this yourself. Is there not a reasonably inexpensive commercial system available you could use? Maybe a single user system would work, or one for a small number of users. That might be much more effective than doing it yourself.

An experienced developer might put something together in a few days, but learning and building a real system at the same time is going to be much more challenging.
 
No need to apologize - you are doing well. If I can just review some things you have said:

For a veterinary clinic. - 1 only
Your clients (in the client table) I presume are people, but as a vet clinic it is the animals that are treated - so perhaps you need a separate table for Clients and Animals (a Client can have multiple Animals). A Visit occurs when a client brings an Animal to the clinic - no offsite visits? Do you want to allow for this or perhaps later another clinic? At a Visit, one or more treatments are applied (instanced through a TxApplied table) which identifies each Treatment (type) - it may be medication, vaccination, some other procedure, or investigation to diagnose or treat the animal (if it can be generalised to this level). The animal then may have one or more Conditions as diagnosed through TxApplied.

Initial thoughts - preliminary schema - that you might consider how it corresponds to yours:
View attachment 121218

Depending on generalisations Procedure/ Medication / Vax might able to be combined into Treatment, designated as types. and VaxApplied to TxApplied. It is difficult to comment on the attributes you have assigned to your tables. The process to review and assign these attributes is called database normalisation. A fully specified vet clinic schema would appear much more complex than above however I assume you are trying to keep it simple.

You do need to apply referential integrity constraints in your schema.
Not sure if you mean Aftermath - as the consequence of an action - or Outcomes - as the result or effect of a treatment.

Re deletions - whether normal use permits them or not, you will need to set the constraints up so that say a client record cannot be deleted in visit records exist for the client. Records can be effectively hidden and not deleted by using an IsArchived flag (on the client record for eg when they are no longer a client or on an animal record if the animal has died. The data can still be accessed for reporting but may not be visible for entry of data.
ok, i see that we will dig deep , i will reply in few days about this.(y)
& i will include my diagram of how everything works and are related to each other.
it is very simple database, as i am beginner in this one. And i want to keep it that way - as much as possible.
 
Before you build this yourself. Is there not a reasonably inexpensive commercial system available you could use? Maybe a single user system would work, or one for a small number of users. That might be much more effective than doing it yourself.

An experienced developer might put something together in a few days, but learning and building a real system at the same time is going to be much more challenging.
Some say that it is possible in wordpress? but i haven't tried it. i don't know other inexpensive commercial system available for database. Ofcourse big clinics use some logistic solutions which is expensive for just 1 clinic.
and i think MS ACCESS can bring the minimum and more just fine. because for our needs it really doesn't need to do much to make us happy and stop writing everything on paper.
 
Agree data should not be deleted but you will probably need a ‘termination’ field for when a client or vet leaves the practice, a pet dies, a vaccine is no longer available etc. usually a date field (where null means current) perhaps with a second text field to indicate why
 
Agree data should not be deleted but you will probably need a ‘termination’ field for when a client or vet leaves the practice, a pet dies, a vaccine is no longer available etc. usually a date field (where null means current) perhaps with a second text field to indicate why
i have termination check box, which gives me back label big red - DEAD. it is only termination option i have.
but it doesn delete client nor animal or other data. it is just info. and in that way - info always stays put. because if there is some inspection - i can show - hey here i had this client, done that and that, and in the end where that!
 
Think about this database maybe like one user type database.
maybe then it makes more sense. like doctor have its laptop, goes with it everywhere and have its own database in lap. database can give you report about what have done. for it self it keeps just data what is done and what need to be calculated and later given to authorities as health inspection and such.
For me - i think it does all i need. maybe the structure could be more clean.
 

Users who are viewing this thread

Back
Top Bottom