Hi,

just a "thing" I would love to do one day... is there a way to validate the database against the entities generated with LLBLGen? My colleagues often use their own database for testing, and right now they just upgrade the version number stored in the database to keep working when I built a new release. However, when I modify the database, they only notice it later on... is there a way to check in advance?

        public static void ValidateGrid(string objectName, DataGridTableStyle style, bool isDal, string originatingClass)
        {
            try
            {
                Type type = ((isDal) ?
                    s_DALassembly.GetType("Dipica.BM.DAL.EntityClasses." + objectName + "Entity", true, true) :
                    s_assembly.GetType("Dipica.BM." + objectName, true, true));
                foreach (DataGridColumnStyle dgcs in style.GridColumnStyles)
                {
                    PropertyInfo pi = type.GetProperty(dgcs.MappingName);
                    if (pi == null)
                        SharedFunctions.MailAndDisplayError(
                            new SharedFunctions.InvalidParameterException(dgcs.MappingName + " does not exist in " + style.MappingName + " for " + type.Name + " in class " + originatingClass + "!"),
                            "Helpers.cs", false, false);
                }
            }
            catch (Exception ex)
            {
                SharedFunctions.MailAndDisplayError(ex, "Helpers.cs - " + originatingClass, false, false);
            }
        }

The code above I currently use to validate the columns used in a datagrid with the object from our own objectmodel (built upon LLBLGen objects) or from LLBLGen directly (the real DAL). Do I have to loop through entities for validation and see if all properties of the entity return a value?? Or is there a more global approach?

Thanks,

Koen

I think you may use the DDL SQL templates (found in the Tasks and Templates download section) to compare against the existing database schema.

The templates generate DDL SQL for Tables/FK/UC/PK and sequences. The DDL SQL is generated from the current loaded catalog(s)

What about creating a method where you loop through all entities and do a simple fetch for one record (entitycollection). If the fetch (=select TOP 1 * from entity) fails, then you know the schema is not in synch with your datalayer.

It's a start....

grtz, Danny

If the schema meta-data itself is necessary to be checked, you can't rely on data. If the entity has 10 fields and one adds a field, that field isn't fetched but you won't notice.

Appoint one schema as 'leading' and all other schemas should simply follow. It's the same with sourcecode: you also have one leading tree (trunk) and everything else retrieves its code from there (checkout/update).

If a developer can work on his/her own schema, extract DDL from that and merge that with yours. I think that's the only way to obtain proper schema differences.

Agree, that the most thorough approach, but if your entities are based on the leading schema and simple single-record fetches work fine on a "copy-schema", then you could conclude that you're working with a valid schema without to much hassle on comparing issues.

Of course, to be absolutely 100% sure about similarity....then you have to compare schema's by using DDL.

gtrz, Danny

Hi,

thanks for the feedback! I'll try to figure out how these DDL things work

Koen