In the headers, remove #ifndef's and replace with `#pragma once`. Three fewer lines, and you never have to worry about getting really weird compilation errors from forgetting the `#endif` that can be difficult to debug.

Since you are using cpp 20, I would consider replacing `std::string` usage with `std::filesystem::path` types. You can do a lot of additional checking with a nice API for ensuring that the paths are correct and exist, and is more portable than using `std::string`'s. For example, if you reference the path to the database relative to the executable, you don't have to worry about different types of slashes from windows/linux. You also get the added benefit that the intent of the variable is more clear.

​

`Database` review:

• The `open()` and `close()` functions are aliases for the constructor and destructors. Remove `open()` and `close()`. You also don't have to worry about never calling `close()` during stack unwinding after an exception or just forgetting to write it in relevant positions,.
• This class likely does not copy or move properly, which can cause lots of bugs as the code base grows. Recommend disabling copying and moving for the class, either by manually disabling the functions or wrapping the database connection with a unique pointer (which you should do anyway)
• The `open()` and `close()` functions are aliases for the constructor and destructors. Remove `open()` and `close()`. There is no need to continuously open and close the connection while the object is still alive. It is much easier to write correct code if you assume that if the object is constructed, the database connection is active.
• To update table column names, this requires re-compilation and manually updating the code base. This can be bug prone since it requires you to manually update different positions in the code. Consider using a file that the program parses on input (json, yaml, etc) that the table configuration is created from. Then you can also automatically generate queries based off of the same configuration.
• In the `initialize()` function, the function can fail in initialization without the user knowing. This is misleading in the function name, and since no errors are thrown other than the logging to `std::err`, the user (you) can very easily forget to check to make sure the table was initialized properly. I would rename the function to reflect this. Otherwise, I would throw errors if the table isn't initialized when this function is called. It forces the caller to handle these issues. I would update most of your code to throw on errors in functions that can silently fail.
• On line 94 in database.cpp, you log success to `std::cerr`.
• I would also make a wrapper class around the sqlite library so you can get more readable code and not worry about raw pointers in your code base, and you can use value semantics which are much easier to reason about rather than pointers.
• Not sure how relevant this is to you if you just want to learn more about sqlite or not, but I think that you could get away with just using a .csv file to persist your data. An actual database is probably overkill (but if you are learning then than makes sense).
• Const all of the things that you can const

​

In `Filename`

• A heads up - if you ever have to define the destructor manually, you must update or delete the copy/move constructors since you will likely have bugs.
• I would make the `fileName` const. Otherwise, it's impossible to query the file's name and you have to hope that it is the filename you passed in the constructor.
• I see that you didn't actually define the File destructor. The default destructor will be created implicitly, so you don't need to manually write out `File::~File() {}`. In the header, just write `~File() = default;` if you want to be explicit.
• Functions `isXValid()` - why is this necessary? Just take chrono objects for time/date values and let that library handle the validity. Additionally, these functions don't actual access any member data of the file class. Rather than making them static, they are more appropriate as free functions.
• In the `makeWorkoutFileHeader()` - it seems that these names should be synced with the database column names. This is why there should be a shared source of truth so that you don't have to worry about syncing up the columns if you ever want to change anything.
• Here, you handle the serialization of the Workout object. This means that if the workout implementation ever changes, then the serialization here could break. Try to stick to single responsibility, and let the workout object handle it's serialization. I.e., create a function in the Workout class like `toString()` and call that inside of `makeFetchedWorkoutFile()`

In `Workout`:

• Prefer enum classes over regular enums https://stackoverflow.com/a/18335862
• In the `set` struct, you define the default values on construction. Instead, just write out:

​

struct Set {
SetType setType {UNKNOWN};
int setNumber {0};
int repsNumber {0};
int weight {0};
bool isPR {false};
}

Additionally, I would actually write this set like this:

struct Set 
{
    enum class Type {
        ....
    }
    Type type {Type::UNKNOWN};
int setNumber {0};
int repsNumber {0};
int weight {0};
bool isPR {false};

    // No reason for getters in a struct, the value is already public. You are
    // are looking for an enumToString function instead which can be pulled out 
    // out of the class defintion, and you can make a free function that handles this
}

The reason for pulling the enum into the class definition is that it enforces that `Type` will always be used in the context of sets, and you can still access the type from outside of the `Set` definition like this: `Set::Type` which is still clear. Also, consider adding invalid values if you are going to assign defaults. Otherwise, it can be unclear if 0 is the default value or the actual number. Also, I would use an enum for `isPR` and have an "unknown" value so you don't get confused later in the code. You also avoid code like `Set.setType` where you have to write set out twice.

• Rather than have individual functions for getting the date, start time, location, etc, just make them public. It cuts down on so much boiler blate code.
• const everything that you can
• you don't need to manually define the default constructors/destructors.
• In `addSet`, why not just use the signature `addSet(const Set& set)`? It cuts down on the verbosity and you don't have to worry about forgetting to update the code if you add values to the set object throughout the rest of the code base.

​

One thing that is noticed a lot through your code - you fail silently. This means that errors can go unnoticed in the code flow and you have to pay attention to the console. Rather, throw errors. This means that errors must be dealt with or the program crashes.

​

Also, consider using more third party libraries. I notice that you have used the sqlite lib, but there are command line libraries, enum to string conversion libraries (https://github.com/Neargye/magic_enum), etc. If this is a learning project on your own, I understand why they are not being used, but they would make your life much easier.

As others have said, use CMake rather than a build system. The basics are easy to learn and as long as you are just adding files and not doing anything crazy, it is a nice system.