DataBasin 1.1 S released

DataBasin 1.1S and DataBasinKit have finally been released, after a long time-span.

This release is dedicated to my late friend and colleague Steven Rovelli (hence the "S" in the release name) who parted from us too young. He was an enthusiastic user of DataBasin and used and supported it inside our company, for countless AMS tasks. COVID-19 carried him away and he will be sorely missed.

This release is marks also the move from the GAP svn repository, to standalone projects on GitHub.

DataBasin sports some interesting news:

• Improved interface with ComboBoxes to select update/insert objects and preferences to filter out more system objects
• remember last successful login username
• getUpdated / getDeleted
• Undelete
• Improved support for sub-objects and lists and unpacking (from DataBasinKit), this allows for example to use sub-queries, provided the related object is one (LIMIT 1)
• support for enabling Assignment Rules in create/update

The core DataBasinKit has also many improvements,, some of them are not completely appreciated from the GUI interface, but useful for other programs wishing to use the API:

• enhanced and rewritten handling of sub-objects and object-lists in query results: this allows to have SObject lists interpreted as such when using subqueries.
• getUpdated and getDeleted
• undelete
• possiblity trigger Assignment Rules in create & update
  

DataBasin + DataBasinKit 1.0 released

A new release (1.0) for DataBasin and its framework DataBasinKit is out!

This release provides lots of news, most of the enhancements coming from the framework and exposed by the GUI:

• Update login endpoint to login.salesforce.com (back again!)
• Implement retrieve (get fields from a list of IDs, natively)
• Support nillable fields on create
• save HTML tables and pseudo-XLS in HTML-typed formats
• Fix cloning of connections in case of threading
• Implement Typing of fields after describing query elements (DBSFDataTypes)

DataBasin is a tool to access and work with SalesForce.com. It allows to perform queries remotely, export and import data, inspect single records and describe objects. DataBasinKit is its underlying framework which implements the APIs in Objective-C. Works on GNUstep (major Unix variants and MinGW on windows) and natively on macOS.

DataBasin - object inspector and updates

First, the underlying DataBasinKit framework got an important update.
[DBSoap update] now supports setting fields to null. That was quite a major detail missing: you could reset to blank even string fields.
This required me to fiddle a bit to generate the fieldsToNull list. Every field passed with an empty string value is considered to null.

<update xmlns="...">
<sobject xsi:type="sf:Account">
<id>....</id>
<fieldsToNull>AccountNumber</fieldsToNull>
<fieldsToNull>OtherCity</fieldsToNull>
<Name>New Name</Name>
</sobject>
</update>

The Object Inspector, the handy tool which allows you to inspect all field values of a record and knowing immediately their developer name given the Object Salesforce Id, how got update powers!

As the Screenshot (here on MacOS) shows, changed values show in a different color (non-updatable fields show in italics and their Cell is not editable). The total number of fields to be changed is summed up in the status field. Only fields marked as changed are updated when the Update button is pressed, other are left as-is and not overwritten for safety.

Further work has been done in the Inspector and full search filtering is now available!
Just entering a a sting will filter out the relevant rows. Both the Field Name or Developer Name are matched, as well as the content! It is thus super-easy to look for all fields (also fields not at layout) which have a certain Value. All fields false? easy as in the screenshot:

DataBasin and DataBasinKit 0.9 released

After more than a year of work, finally a new release of DataBasin and its associated framework. This version features a Framework that can be used in threads and the application itself is capable of having concurrent connection classes to SalesForce.com.

On Windows

On OpenBSD

Countless bug fixes (thanks to the bug reports of my colleagues Diego, Moustapha, Matteo + Matteo).

Major new features are:

• threadable DataBasinKit framework
• concurrent, interruptible operations (e.g. select vs. update)
• handle multiple errors as a result of update
• filter new lines when writing CSVs
• countless bugfixes, especially in select-identify corner cases

DataBasinKit allows you native connection to SalesForce.com, allowing your application to integrate SOQL queries (SELECT, UPDATE similar operations), be it on Mac (Cocoa) or NetBSD, FreeBSD, OpenBSD, Linux or Solaris as well as Windows (MinGW).
DataBasin itself allows you to perform standard operations in a quick and agile interface: Extract accounts on Linux without the need of Java. Use the unique select-identify feature.

I am proud that Free Software can connect from a Free Software Operating System to a proprietary system and bridge the two worlds, enabling to do administrative work without being constrained to Java on Windows (read: DataLoader). Thanks to the many developers who continue supporting me in the development and keep these fine Operating Systems and tools alive.

Nasty DataBasin bug fixed

DataBasin's Select-Identify, an invaluable tool for many working with salesforce.com, showed erratic behaviour: extremely hard to reproduce even by sometimes re-running the same query on the same data set, the operation would just stop without any error in the console log, trapped exception or else.

After extensive debugging I found the problem in the queryMore method of the API implementation in DataBasinKit. If queryMore had to return just one record, it would malfunction.
Technically this happened because the size reported by Salesforce.com in the queryMore is not the size of the objects of the queryMore, but of the original query.

The problem affects thus anything using queryMore: If you would select and had a batch size in download of 500, you would get a problem with 501, 1001, 1501 records and so on. 500 or 502 would just work fine. Combine this that the query size of the selectIdentify is dynamic and you get the idea on how difficult it was to reproduce.

Now it is fixed and the upcoming 0.9 version will have this fixed. All currently released DataBasin versions are affected by this bug.