Net Talk Client Tables Sync

[Rob Kolanko]

Bruce,
I was experimenting with the desktop and server apps for the NT 9 disconnected app . I noticed that the Tables tab  was blank of the "Sync client tables with server" extension. I assume then that all tables in the client application have to be synced with the server. In the next release, will the developer be able to select which tables are synced?
or am I missing something?
Also the desktop app had FM with the app. I do not own FM. I removed the DLL from the solution and it compiled and ran fine.

How soon to a new NT9 release?

Thanks,
Rob Kolanko

[Bruce]

Hi Rob,

>> I was experimenting with the desktop and server apps for the NT 9 disconnected app . I noticed that the Tables tab was blank of the "Sync client tables with server" extension. I assume then that all tables in the client application have to be synced with the server. In the next release, will the developer be able to select which tables are synced?

I haven't extended it for the next release (although I've hidden the tab for now to make it less confusing.)
At this point only tables with a ServerTimeStamp field (and key) will be added to the queue. And it is just a Queue (so you can remove records in embed code if you like.)

I'm not sure that there's a use case for tables which have a ServerTimeStamp field, but should not be sync'd. I guess we'll find out.

>> Also the desktop app had FM with the app. I do not own FM. I removed the DLL from the solution and it compiled and ran fine.

that's fine. I was using FM3 during development of the app, and if I change structures it makes it easier for folk to upgrade the example, but it's not core to the functioning of the example.

>> How soon to a new NT9 release?

I've been testing 9.02 over the last couple days - I was hoping to have it up on Friday, but was delayed by a bug or 3, so maybe today if all goes smoothly.

Cheers
Bruce

[Rob Kolanko]

Hello Bruce,

At this point only tables with a ServerTimeStamp field (and key) will be added to the queue.And it is just a Queue (so you can remove records in embed code if you like.)

Okay, I was afraid that the procedure tried to sync all the tables declared in the app.

I'm not sure that there's a use case for tables which have a ServerTimeStamp field, but should not be sync'd. I guess we'll find out.

I believe there are special cases where the programmer may wish to do build their own sync API. For example,
I have a new table for mobile users that has the password, rights and other information of the user to be stored on the mobile app I am writing for Windows. I made the table with the ServerTimeStamp field (and key), but I have made my own code API code to sync this only current users record of the table directly to control security and I only keep the records for the users of that device, not a complete table sync. For now, I will remove the table from the queue. Later I may rename the ServerTimeStamp field, or find that I will have to use the sync methods provided to work with the phone gap app.

Thanks,
Rob

[kevin plummer]

I would like to have more control over the sync than just the ServerTimeStamp field as I use the one dictionary with multiple apps + I have added that field to a lot of tables but I may change my mind during development or production and I would rather leave the field in the table dormant. Hope that makes sense...

Kevin

[Bruce]

That makes sense Kevin, but for now just remove those tables from the queue in embed code.

cheers
Bruce