Solved Begginer! please help.

FeelCore

New member
Local time
Today, 02:56
Joined
Aug 20, 2025
Messages
17
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.
 
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.
What I meant is... I just googled "software for vets " and got a list of a number of packages. None of them are really saying how much their solution costs, but if you know any of them from other vet practices you might get some help. Doesn't your national vets association have some advice. It's probably going to be much easier this way than rolling your own.
 
Last edited:
I did look at this template to see if there was something worth using.
and although it is not super expensive I could build something better than that in 20 minutes. That looked pretty bad, at least from the demo.

There has been a few example of medical clinic or even a animal clinic on this site. I would look here too. Of course I checked and could not find any of the ones I remember seeing.
I believe @zelarra821 was doing some work for a Vet and may have some insight. You could PM him.
 
The template referred to shows nothing that relates to the animals treated or the treatment they received - just a generic appointment schedule - so pretty useless.
@FeelCore - The report to do with health inspections: is that a formal, regulated report that needs to be completed for certain diseases? You need to make sure all elements for the report are captured.
As you travel in the field to locations, the appointments have a location - where it might be at the practice, or at a client/ other location. This means the Appointment will need a flag to indicate - At Practice or in Field, and if the location is not at the client's address (or at the practice), then an ability to capture the location of the appointment.
Is an Appointment always for a single animal or perhaps a herd? Treatment applied will need to be specific to an animal I presume. But may be a mass vax might be applied to a herd at an appointment - but each animal in the herd needs that to be recorded as having been vaxed. Might be going too far for your initial foray into Access, but...
 
and although it is not super expensive I could build something better than that in 20 minutes. That looked pretty bad, at least from the demo.
It's better than a lot of demos but $100 would be a lot to pay for it given it's improper normalization and lack of treatment details
 
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.


Hi, sorry for such delay!
I attached my view of how i see and made my database. in simple way.
i hope it makes more sense to what i have created.
i have made other version, where i added field in each table - client, visits, medication, vacination. made log_on table where it takes tempvars and store info, then this info, if created new record or is edited it fill this field with example Dr.name, and then you know wich doctor made that record or touched last! :) it manages problem if there is 2 doctors in clinic - for example!
 

Attachments

  • database structure.png
    database structure.png
    81.2 KB · Views: 35
The template referred to shows nothing that relates to the animals treated or the treatment they received - just a generic appointment schedule - so pretty useless.
@FeelCore - The report to do with health inspections: is that a formal, regulated report that needs to be completed for certain diseases? You need to make sure all elements for the report are captured.
As you travel in the field to locations, the appointments have a location - where it might be at the practice, or at a client/ other location. This means the Appointment will need a flag to indicate - At Practice or in Field, and if the location is not at the client's address (or at the practice), then an ability to capture the location of the appointment.
Is an Appointment always for a single animal or perhaps a herd? Treatment applied will need to be specific to an animal I presume. But may be a mass vax might be applied to a herd at an appointment - but each animal in the herd needs that to be recorded as having been vaxed. Might be going too far for your initial foray into Access, but...


The locations is clinic and not somewhere else and yes animals is treated one by one. so no problem for location field in my clinic. ( but thank you for insight - i will think about that too, noted)
This clinic data holds more like an notebook type, useful only for Doctor and its work basis.
Not for clients. clients have only Report what is done in appointment so doctor doesn't have to write it down manually on paper.
For Health Inspection it holds info about [medication] and [for what client is used] and [how]. it shows [how much came in] and [how much it goes away], and [what is left on site]. There is No Report form for Health inspection, only Form with data, calculated data.
Vaxed info makes doctor to easy fill up form in Health Inspection excel sheet by period selected.
Other info is just history for doctor to see what is done in visits.

You can imagine - old time when all was on papers - so doctor went for clients card, which holds info about patient and if needed treatment doctor wrote on paper what needed to done to get healthy again. And made some note in clients card, so he can remember history of patient.

So my database does same job with some extra calculated fields so doctor can fill up forms for other companies if needed.

My concern is more about how it is done as programming - VBA, Security - how to lock my database and protect, for me and for clinic!
I tried on my other PC to set up. and it was quite circus. original ok - all language change, made it work, but when i made ACCDE file for locking my VBA it made some event errors. why? I don't know.
I have to think about [client and animal] separation in future, [Location change] if doctor is on road and if treating herd animals.
 
Hi, sorry for such delay!
I attached my view of how i see and made my database. in simple way.
i hope it makes more sense to what i have created.
i have made other version, where i added field in each table - client, visits, medication, vacination. made log_on table where it takes tempvars and store info, then this info, if created new record or is edited it fill this field with example Dr.name, and then you know wich doctor made that record or touched last! :) it manages problem if there is 2 doctors in clinic - for example!

It would be helpful if you could post an image of the database's relationships window, set out clearly so that the tables and all of their columns are readily visible, and the relationships between the tables are readily apparent. This would enable us to judge whether the tables are correctly normalized or not, and whether the relationships between them correctly reflect the real world relationships.

From the diagram you posted you appear to have a single table for clients and animals. These are separate entity types, however. By combining them in a single table, if a client registers more than one animal, this would introduce redundancy into the table as the client data would be repeated. To correct this a Clients table should be referenced by an Animals table in a one-to-many relationship type on ClientID or similar.

You apparently have a column in the Visits table whose bound control is a combo box whose RowSource property is a value list. If the value list is a set which is immutably fixed in the real world, e.g. days of the week or months of the year, this is acceptable. If the values are data on the other hand, the data is being encoded as part of the object definition. A fundamental principle of the database relational model is the Information Principle (Codd's Rule #1). This requires that all data be stored as single values at column positions in rows in tables, and in no other way. In this case, therefore the values should be distinct values in a column in a referenced table, and the RowSource should be a query on that table.
 
Commenting upon the database-structure-png:
You have made a decision to combine Client and Animal in the one table. That would appear a serious error in design. A client may have multiple animals, at any one time, and the animals a client has and brings to your clinic for a visit does change as time passes. On each occasion you enter a new animal in your database belonging to a client you will need to enter the same Client data. Besides the issue of re-entering the same data (asusming it is exactly the same). Further, if the client changes address or phone or ... you will have to find and edit each of those records to keep them in sync - else you are also introducing the problem of what data to trust when it comes to writing say a report on the treatments / vaccinations given to the animals of that client.

In your diagram you refer to the use of a combo box with a value list. It is unlikely that that approach is best practice. Generally a lookup table is used for these values, with a foreign key to the value in the Visits table. That will give you greater control and flexibility to use a form to manage such values, rather than using the design view. (I know, at this time it is just you that the app is being developed for, or may be one other if there are other Drs. but you will need to use design mode to change these values, whereas the form will not require this).

Regarding your next post - it appears that you want to "protect" your database from unintended design changes by users. That can be done - however note the advice in the previous paragraph. You will need to retain a master copy of your .ACCDB files (one for the front end, one for the back end). Without going into further detail you can generate an ACCDE file for the front end containing everything other than the data, which prevents users from making design changes. Updates to the front end involve simply replacing the previous front-end file (the ACCDE). The back end contains your (shared?) data. You need to ensure you keep backups of your data AND when working on changes to your app you need to work on a development/test database. Introducing changes to the backend can involve migrating data - which involves creating and testing action queries in your database. A shared back end is an ACCDB - but users only should have access/visibility to it through the front end - forms and reports (with login capability - so the last change to records can be easily traced).

I hope you are happy with your progress. An update to show your current database will help, even with the language problems.
 
The locations is clinic and not somewhere else and yes animals is treated one by one. so no problem for location field in my clinic. ( but thank you for insight - i will think about that too, noted)
This clinic data holds more like an notebook type, useful only for Doctor and its work basis.
Not for clients. clients have only Report what is done in appointment so doctor doesn't have to write it down manually on paper.
For Health Inspection it holds info about [medication] and [for what client is used] and [how]. it shows [how much came in] and [how much it goes away], and [what is left on site]. There is No Report form for Health inspection, only Form with data, calculated data.
Vaxed info makes doctor to easy fill up form in Health Inspection excel sheet by period selected.
Other info is just history for doctor to see what is done in visits.

You can imagine - old time when all was on papers - so doctor went for clients card, which holds info about patient and if needed treatment doctor wrote on paper what needed to done to get healthy again. And made some note in clients card, so he can remember history of patient.

So my database does same job with some extra calculated fields so doctor can fill up forms for other companies if needed.

My concern is more about how it is done as programming - VBA, Security - how to lock my database and protect, for me and for clinic!
I tried on my other PC to set up. and it was quite circus. original ok - all language change, made it work, but when i made ACCDE file for locking my VBA it made some event errors. why? I don't know.
I have to think about [client and animal] separation in future, [Location change] if doctor is on road and if treating herd animals.
Hi
I believe you need to have a rethink on the structure of your tables.
The attached is an example Relationship Diagram produced by Github.

See this Link
 

Attachments

  • Vets.png
    Vets.png
    73.4 KB · Views: 33

Users who are viewing this thread

Back
Top Bottom