Hi developers, as far as I can see when I export a table to csv the metadata is not included (even if it the "show meta data" check box is checked) and therefore I loose the record creation date which in my case is needed.

Can this feature be added?

Thanks

I have recorded the 2 cdbBlobs Code snippets.
The first one is an error.
the Highlighted portion of the code snippet shows: cdb_delete "cdbBlobs", tReordIDs,"cloud" in an error.
This is the same for the 2nd snippet also.
The snippet for the Batch delete is correct.

Here is some sample code on how to use cdb_batchSync

//THIS API WILL SYNC MULITPLE TABLES AT ONCE
//pInputA: This array contains primary keys of tableID. The secondary keys are
//(cdbRecordID,source,allowDeletes,detectCollisions)

—REPEAT THROUGH ALL TABLES AND BUILD AND INPUT ARRAY
—THIS EXAMPLE WILL DO FULL TABLE SYNCS
—YOU COULD SWITCH OUT THE ‘*’ FOR LINE DELIM RECORD IDS IF YOU WANT TO DO PARTIAL SYNCS
repeat for each line xTableID in cdb_tableID("*")
  put "*" into tInputA[xTableID]["cdbRecordID"]
  put “cloud" into tInputA[xTableID]["source"]
  put true into tInputA[xTableID]["allowDeletes"]
  put true into tInputA[xTableID]["detectCollisions"]
end repeat

put cdb_batchSync(tInputA) into tResults
if not cdb_result() then
  put "Error:" && cdb_result("response")
end if

Hello everyone,

We just pushed another update that fixed some regression bugs and contains some new features.

We will need to update the documentation for the APIs to reflect these recent advancements.

######## VERSION 2.3.7 (2019/10/11)
News: IMPORTANT CHANGES! While not required, it is highly suggested that you export the Toolkit to take advantage of these improvements.
- - - - - - - - - -
Added: New batch sync API: cdb_batchSync

Improved: Updated cdb_tableID to accept '*' as a param. This will return a list of all tableIDs filtered without cdb* (internal tables)

Bugfix: Fixed a regression bug where cdb_batchCreateLocal would not allow cdbRecordIDs to be passed. If you desire to pass your own cdbRecordID, please pass it in tInputA["cdb"]["cdbRecordID"]
Bugfix: Fixed a regression bug where cdb_batchCreateCloud would only store the first record in the database for each table.

Hello friends. We pushed version 2.3.6 late in the day yesterday. LiveCloud Manager will automatically download the udpate for you. We highly suggest you update your projects with the new libraries. All of the regions have been updated as well.

######## VERSION 2.3.6 (2019/10/09)
News: IMPORTANT CHANGES! The CanelaDB libraries have been updated with improvements in performance. While not required, it is highly suggested that you export the Toolkit to take advantage of these improvements.
- - - - - - - - - -
Improved: Optimized performance of cloud writes by not repeating 3 times on failed attempts. This would cause unnecessary wait times.
Improved: No longer looking for a response from the server when doing a sync of source "local". This will improve the performance of sync significantly because the server was sending back the entire synced data set unnecessarily.
Improved: Cloud responding to clients of sync with source 'local' to keep compatible in the event older libraries are still in service. But, sending very light data back to give clients using older libraries a big performance boost.
Improved: Updated the read related APIs to read missing data from the cache system through the instance.
Improved: csi_writeCacheFile changed to write request with the TableID instead of a UUID. Makes it easier to debug.
Improved: Removed deprecated code from csi_deleteCloud
Improved: cdb_batchCreateCloud has schema checker turned back on
Improved: cdb_batchCreateCloud will officially allow recordIDs to be passed in the cdb portion of the array
Improved: cdb_batchCreateLocal error checking code has been brought back
Improved: cdb_batchCreateLocal will will enable you to pass your own recordID in the cdb portion of the array
Improved: cdb_batchCreateLocal will now clean the cdb portion of the array
Improved: csi_configCache will store the cached file to disk vs just putting it in RAM.
Improved: Updated batch sync to work with recent changes to read from cache code.
Improved: Made checking for multi-part processing more aggressive
Improved: Shortened the default value for rebuilding of full table cache
Improved: We now build cached configs with an authKey
Improved: Updated all cache building calls to include pRead and pContext values

Bugfix: Log cleaning bugs fixed
Bugfix: The cloud instances were improperly using the passed tableID with cdb_teamID in cdb_lookUpValueLocal. This caused the call to fail and return empty data to the client.
Bugfix: Cache rebuilding APIs will not rebuild all the tables when passed 'true' in the config file.
Bugfix: Cache rebuilding bots would hang if a bad tableID was passed
Bugfix: Changed returned result format for cache downloading to include both true and false results from downloading. This enables other APIs to know what we received from the cache and what needs to be downloaded from the instance due to missing cache files.
Bugfix: cdb_batchCreateCloud will replace index with recordID. This was needed for the caching system to work with creates. The result before this fix was a cache that was built on the index value instead of the recordID. Thus, no one would be able to read that record. Also, it would replace itself with the next createCloud.
Bugfix: Modified where the hardware id is stored for mobile devices to the 'cache' folder. This aligns with were we store other CanelaDB files where we need write permission.
Bugfix: cdb_pingNode() does not work if you pass a table name.
Bugfix: Removed shell calls from mobile setup APIs as mobile OS will not allow shell calls to be made.
Bugfix: Freshly created accounts that do not authenticate afterward will not be able to loadTable with freshly stored data.
Bugfix: When creating a new account, the developer would not be able to decrypt cached files.
Bugfix: When receiving an updated config data, the needed data from the download was not properly saving the updated data inside of the locally saved config file.
Bugfix: Instance caching system was not playing nicely when tasked to cache multiple tables at the same time.

Hi all
Just starting with livecloud. I have tried various methods based on the docs and I have also used the crud sample stack but I cannot get livecloud and LiveCode to talk. I just keep getting the candela sdk missing please export again. One thing I have noticed is that the api and data folders are not exported?
This is so frustrating

Can I have more than one BLOB Table or is this a reserved Table?

I have my BLOB table and I added a key called "Comment".
I decided to change the name of this key to PrjType and did a refresh. I had 7  comment key items until I changed the name. Now I have only 4.
This only affected the items in the "Comments" key. I will just rebuild my "Comments" but I thought you guys might be interested in this.

We are working on training videos. Our goal is cover all the basics in the first videos and progress to more advanced topics afterwards. We are going to strive to produce a few videos every week. Yesterday was day one. The video was just published on YouTube. The first video is covers downloading LCM and creating an account. How to create a LiveCloud Account

We will update the website as well to have links to the videos. Our working list of videos includes:

Forgot Password
Main screen overview
Code builder
Query builder
First project
Building a standalone
Account Management
Trying the sample projects
cdbUsers Table
Authentication
Arrays

Each video has sub categories. We plan to have an outline on videos that cover sub-topics with timing on the outline. Thus, you can jump to a particular section quickly. There are more topics to cover. We are basing the videos off feedback and comments from all of you. We want to solve as many getting started pain points as soon as possible.

We are pretty excited about meeting your back-end needs and training content is a critical part of this goal. Enjoy and happy coding.

If I do an update -say add or delete a record- (all this is done with the records locally) and I shut the application off before the cached records are updated to the cloud? Are these local records held in limbo until I restart the program? I assume so. If someone else updated the same record before I restart my application, which update takes precedence? The assumption is: the other update was completed and updated to the cloud before I restart the previous computer with the application.