Hey, I'm just trying out LLBLGen over the last few days and I must say I'm impressed. Its a bit daunting at first as there is a lot to get your head around.

My project consists of a Xamarin.Forms android app with SQLite database and MS SQL server database for the backend. I'm not 100% sure, but I think I need to setup some conversion for certain values such as Guid as these are stored differently in SQLite.

I'm using EF Core 3 and .NET Standard 2.1

I generated my models from the MS SQL database and since there is over 50 table and several Guid's and other types that need converting, I tried to set a automatic converter converter as specified in the docs.

I've added converters to by going to Project, Settings, Type Conversions, Add new...

but when I generate the C# code, I don't see anything about the converted types. What am I missing here ?

Also in the Field Mappings for each entity, the "Type Converter to use" drop down, is always empty, regardless of field type.

Thanks !

Thanks for the kind words

Could you check if the type converter is loaded when you click on the 'tools -> view loaded external types' ? (After you've loaded your project of course).

It can be the type converter isn't loadable by the designer. E.g. if you compile your type converter against .netcore 3.1, it won't load as the designer is a netfx app. In that case, dual target the type converter csproj to include net452 in the <targetframeworks> element in the csproj, and use the net452 build of the type converter dll in the designer.

Thanks for the reply. Just to be clear this is not a converter I have created, I'm just trying to use the built in ones, in particular the GuidByteArrayConverter.

I've checked and it seems all the converters are loaded.

To keep it simple; my models are created based on a MS SQL database so this causes errors when they are used with the client as it is using SQLite. So types such as GUID in MS Server are stored as Byte[] in SQLite.

So the question is, how do I use LLBLGen to set my Guid fields as byte[] even when the models are synced with a MS SQL server.

Hi there,

I think TypeConverter is not what you need here. A TypeConverter takes a DB field .net type and converts it to a Model field .net type, and back. So when you fetch an entity from DB it comes with this DB field .net type and converts it to this model field type. Then you save the entity, so the model filed .net type is converted back to the DB field type which is what the connector (and so the DB) is expecting.

The GuidByteArrayConverter takes the DB field type "byte[]" and converts it to a Model field type "Guid" and vice versa. Tha's why you don't see this converter in the available converters for a field, because the db field is not byte[] so it's not a candidate for that converter. This is extracted from the System Type Converters documentation page:

Guid <-> byte[]

Type: GuidByteArrayConverter

Db field .NET types supported: byte[]

Frameworks supporting this conversion: Entity Framework Core 2.1+, LLBLGen Pro Runtime Framework

Your problem is different: you are modeling with different types that the ones you are using in runtime. Some possible solutions:

A. Create a database with the types you are looking for. In this case, BYTE[] instead of GUID. And use this database for modeling. No TypeConverters required.

B. Edit the DB field type definition in LLBLGen. This is like telling LLBLGen Designer: "Guid is not the correct DB Type, it's byte". The problem with this is that in each synchronization the type would cause conflicts.

C. Sames as B, but you don't use Database First approach, but Model First. You then change all the DB field definitions and Sync, this would generate an ALTER script that you would ignore.

I would recommend that you take option A, as it implies just a "Find and Replace" operation in a db script, and it's more clean and natural.

I hope that helps.

Hey daelmo, thanks for the in-depth reply.

After many wasted hours with LLBLGen, I worked out that TypeConverters were not what I needed.

The situation I have is a bit more complex but I tried to keep it simple for clarity. I have to stick with the Database first option as this is already in place and heavily populated with data and relations, it would be too much work to transform it all.

One of the main problems is we use a Middleware to "sync" the data between the client (mobile device) and the backend server, so we are restricted to what we can use.

In this case, I think its easier to write a simple ORM and just convert the fields required.

Again, thanks for your time !

You still have to communicate with a service, right? So create a derived model (DTOs) of the entity model in the llblgen pro designer, create a service which exposes the DTOs. these serialize to json on your service API, then on the mobile, deserialize them to whatever you want to use there and store them locally. Sending them back to the service, you can easily update entities with the generated code for the derived model: we generate persistence logic to update an entity with a dto's data, so that's pretty straight forward. You can decide what fields to expose in the service, denormalize the fields in the dto's, so the model exposed and used on the mobile doesn't need to be the same as the one on the service/in the database (which is likely, considering sqlite doesn't really have any true types).

DTOs readwrite: https://www.llblgen.com/Documentation/5.7/Derived%20Models/dto_ef.htm DTOs in the designer: https://www.llblgen.com/Documentation/5.7/Designer/Functionality%20ReferenceDerivedModelfunctionality.htm

Writing an orm isn't simple, even if it's just a simple thing, plus you still have to communicate with a service from the mobile so you still have to do queries on the service, send the results to the mobile and send data back.

Please give it a look, you already have the entity model, no need to waste that.

Hey, there is no web service which we use directly... The clients have a full cache of the data on the device as it must work in a disconnected scenario. When the data changes and its online, the middleware syncs the changes with the backend. The middleware takes care of creating the sqlite database etc.

I've just wrote some basic CRUD functions over the SQLite package and some converters to allow the conversion between the .NET types and SQLite "types"

Ah ok, then you need a syncing service, which can be a tough nut to crack. We can help you with the server side of things, but the sqlite story and the sync story is not in the cards indeed.