# Marketcircle's Billings -- buggy -- beware



## Guest (Nov 9, 2011)

If anyone is using this app beware, the latest updates seem to be having some serious issues. I just filed the 5th bug in as many weeks, most were not a huge deal (well not data damaging anyway) but this latest one is a nasty one.

I just watched the iPhone version sync with the desktop version and break a bunch of slips. Some were duplicated, others were deleted. Some of the ones that were deleted had already been invoiced, which makes for a big issue when it comes reporting time as there is no way to re-attach a "new" slip to a previously sent invoice.

To test I ran some reporting and it's totally out of whack now :/ Waiting on support to get back to me about how I can resolve this. I've already tried reverting to the last backup (last night) but the iPhone version keeps killing the desktop version, even after deleting and re-installing the iPhone version.

Sadly I think it's time to find yet another timer/invoicing solution. I was very happy with this one until a couple of months ago when it seemed to take a big nosedive.

Their support department is very slow and apparently a lot of them have a pretty poor command of the english language, and unless I buy a support package I'm stuck with email support.

Just wanted to give people a heads up to be very careful with the latest updates ... I'm pretty sure that the iPhone version is to blame but who knows for sure.


----------



## groovetube (Jan 2, 2003)

i dropped it a little while ago for freshbooks. Couldn't be happier.


----------



## Guest (Nov 9, 2011)

Does freshbooks supply a timer component? That's essential for my needs. I've used a few apps over the years but billings was the most complete for my needs do far, or at least until it started mangling and deleting things on me. Between that and massive memory leaks it hasn't been pleasant lately. Going to try and hold off until year end before I switch.


----------



## Guest (Nov 11, 2011)

So to follow up with this one, after a bunch of email exchanges, I gave them a completely plausible technical reason as to why it might be happening, along with a pretty good technical analysis with specific examples of why I thought that this was the root of the issue. They responded telling me that the problem "shouldn't happen" (duh, it's bug, helllloooo), that it was "impossible to reproduce" because of that and then proceeded to paste a bunch of info from their kb as to how to use slips). I replied with more information which including me "breaking in" (their words) to their database sources -- which are sqlite -- and showing them exactly what broke, where it broke, and why it was showing the strange results that it did for a couple of the scenarios. (For the geeky in the crowd the problem was 2 rows of data in one table with the same unique identifier, which they apparently do NOT enforce at the database level, but only in the code -- very very rookie IMHO). Given the timestamps on the rows of data I could even point out petty much exactly when and how it happened as well as showing them why both rows showed up in some instances (running reports) and not in other instances (straight lookups). Again, for anyone that does database type programming this is like database 101 type stuff (well I suppose maybe 201 type stuff).

Their final "official" word on this was to mark the bug as "resolved" and say that "this shouldn't happen" and that if it happens again to let them know but that I should avoid "breaking in" to the data sources directly. Sheesh. I wish I could send them the invoice for the time I took to diagnose their issue. Luckily I could "break in" to their data and fix the actual problem. They told me flat out that it "could not be fixed".


----------



## groovetube (Jan 2, 2003)

mguertin said:


> Does freshbooks supply a timer component? That's essential for my needs. I've used a few apps over the years but billings was the most complete for my needs do far, or at least until it started mangling and deleting things on me. Between that and massive memory leaks it hasn't been pleasant lately. Going to try and hold off until year end before I switch.


yes it does.


----------



## hayesk (Mar 5, 2000)

I avoid MarketCircle's products for reasons like this and other which can be summed up as they have no integrity (no pun intended), in my opinion.


----------



## Guest (Nov 13, 2011)

After having spent a bit more time digging around in their database structures I am definitely going to be moving away from this product. There are some really REALLY poor design decisions in the data structures that are just nightmares waiting to happen. For example setting arbitrary "row" id's that are all placed 100 numbers apart (presumably so they can try and jam things in between at a later date? But I couldn't find any examples of that actually happening) and not enforcing any kind of proper relation or using them as keys is, well, EEEEEK. Run away, it's a trick. The data structures look like they were designed by someone with not much more than a theoretical knowledge of database design (and they skipped some important chapters in their theoretical knowledge as well).


----------



## G-Mo (Sep 26, 2007)

groovetube said:


> yes it does.


Freshbooks doesn't have a native iPhone timer, have you tried any of the iPhone 3rd party timers?

I quit Billings a few years ago and moved to On The Job, however, I am now requiring portable timing (via iPhone) and cross platform support...


----------



## Guest (Nov 14, 2011)

G-Mo said:


> Freshbooks doesn't have a native iPhone timer, have you tried any of the iPhone 3rd party timers?
> 
> I quit Billings a few years ago and moved to On The Job, however, I am now requiring portable timing (via iPhone) and cross platform support...


An iPhone timer is essential for me, that was one of the reasons I went to Billings in the first place. I was just also looking at Studiometry, but it might be overkill for my needs and is more expensive than I'd like. I used to use Task4Time and it worked fairly well, small developer but lots and lots of revision bumps all the time and ran into my share of bugs in the process (nothing destructive though). I want to be off of this at year end.


----------



## groovetube (Jan 2, 2003)

G-Mo said:


> Freshbooks doesn't have a native iPhone timer, have you tried any of the iPhone 3rd party timers?
> 
> I quit Billings a few years ago and moved to On The Job, however, I am now requiring portable timing (via iPhone) and cross platform support...


freshbooks has an iphone app with a timer. I have it on my phone. It's 15 bucks.


----------



## crawford (Oct 8, 2005)

I have used Billings for a few years with no known issues, but I'll be interested to hear what they have to say about this.
I don't think that I do the same kind of work as you, but I'd appreciate knowing why an iPhone-based timer is an essential item. Are you billing time to multiple clients and jobs in a single day while you're away from your main computer? Are the time increments too small to recall at the end of the day? All of this makes me think that I'm being a little too loose with my time-keeping!

Secondly, what criteria will you use to decide which product to migrate to your time-keeping / invoicing workflow? Your issues with Billings clearly go beyond features and UI. To me it seems riskier to move to a web/cloud-based product where you are truly unable to look under the hood as you did with Billings. I'm nervous to move, but in the meantime, I won't be using the iphone app.


----------



## groovetube (Jan 2, 2003)

I wouldn't consider cloud based any riskier that your hard drive. Honestly since switching to cloud based, I have less worry or problems since it isn't on my computer. 0 hiccups whatsoever.


----------



## Guest (Nov 15, 2011)

crawford said:


> I have used Billings for a few years with no known issues, but I'll be interested to hear what they have to say about this.
> I don't think that I do the same kind of work as you, but I'd appreciate knowing why an iPhone-based timer is an essential item. Are you billing time to multiple clients and jobs in a single day while you're away from your main computer? Are the time increments too small to recall at the end of the day? All of this makes me think that I'm being a little too loose with my time-keeping!
> 
> Secondly, what criteria will you use to decide which product to migrate to your time-keeping / invoicing workflow? Your issues with Billings clearly go beyond features and UI. To me it seems riskier to move to a web/cloud-based product where you are truly unable to look under the hood as you did with Billings. I'm nervous to move, but in the meantime, I won't be using the iphone app.


Yes I do service related stuff as well as programming which means that I can be doing work for 6 or more clients in the same day, sometimes on-site which means I need the iPhone timer and I need the ability to sync it to my main desktop version. Also with the iPhone version of billings I am able to track the time and when done immediately email an invoice to the client, which is also something important to me.

The only "risk" I would see with having a cloud based service is the inability for me to personally ensure there are backups. I know that most of those services are probably doing backups upon backups, but I feel much safer knowing that I have done it and that I can restore it if need be.


----------



## Guest (Nov 15, 2011)

crawford said:


> I have used Billings for a few years with no known issues, but I'll be interested to hear what they have to say about this.


I already posted what they have to say about it on the first page. Basically they are convinced that this couldn't happen and that it shouldn't happen and they closed the bug report and marked it as resolved. This seems to be a popular approach for them as they have yet to actually *fix* a single bug that I reported but they are all closed and marked resolved. They have only confirmed that one is even a bug (and that one is also marked as resolved even though it's not) I still have to quit and relaunch billings at least once a day due to a massive memory leak (1.5GB per day of memory) ... that it took them 4 weeks along with dozens of emails back and forth with me to reproduce it, and when they finally did, they marked the bug as resolved and closed it and said that there would be a fix in a "future update" of the application. No time frame or other details, even when I asked when I could expect a fix, they just told me that they have set it up as an internal bug and that I would no longer have access to it and it would get fixed "in a future update"

Needless to say I'm not very impressed with their support. They did offer, on multiple occasions, to sell me a support package. Not really interested in giving them even more money so that they can "resolve" all of "my" (read: their) bugs.


----------



## Oakbridge (Mar 8, 2005)

mguertin said:


> After having spent a bit more time digging around in their database structures I am definitely going to be moving away from this product. There are some really REALLY poor design decisions in the data structures that are just nightmares waiting to happen. For example setting arbitrary "row" id's that are all placed 100 numbers apart (presumably so they can try and jam things in between at a later date? But I couldn't find any examples of that actually happening) and not enforcing any kind of proper relation or using them as keys is, well, EEEEEK. Run away, it's a trick. The data structures look like they were designed by someone with not much more than a theoretical knowledge of database design (and they skipped some important chapters in their theoretical knowledge as well).


I'm just scanning thru this, so I haven't had time to read all of the posts in the thread but I did want to comment on the use of row ID's that are 100 numbers apart. This is not an unusual method for a remote client that has the potential to be multiuser. I realize that you have been referring to Billings which is the single user, but I am guessing that some of the design is shared with Billings Pro, thus the need for creating record ID's that are 100 numbers apart. 

I'm not sure how you were able to view the database structure as it is not open to a standard iOS user. I'd question your very harsh criticism of the design. Complain about the support you received, or the performance of a piece of software, but not the database and application design. 

I've seen databases that followed all of the 'rules' that were horrible solutions, and I've seen databases that broke many rules that were great solutions. Perhaps there were some design mistakes that were made, but unless you were in the room during the design, you don't know the reasons why certain decisions were made. 

This product works, and works well. I've used Billings Touch since it was in beta, and now use Billings Pro Touch. I realize that any user can have problems with data, it's why we stress backups. But I have yet to see any problems with my data.


----------



## Guest (Nov 15, 2011)

Oakbridge said:


> I'm just scanning thru this, so I haven't had time to read all of the posts in the thread but I did want to comment on the use of row ID's that are 100 numbers apart. This is not an unusual method for a remote client that has the potential to be multiuser. I realize that you have been referring to Billings which is the single user, but I am guessing that some of the design is shared with Billings Pro, thus the need for creating record ID's that are 100 numbers apart.
> 
> I'm not sure how you were able to view the database structure as it is not open to a standard iOS user. I'd question your very harsh criticism of the design. Complain about the support you received, or the performance of a piece of software, but not the database and application design.
> 
> ...


The problem with the row id's isn't so much that they are setup 100's of numbers apart (and btw, your argument about multiuser makes zero sense as to why they would be a hundred numbers apart) it's the fact that they do not enforce them as keys at the database level, in other words it's easy for what just happened to me to happen to anyone. If they were enforced at the database level then my database wouldn't have been broken in the way it was.

Their support is atrocious, they have dropped the ball at every step of the game and done nothing but tried to sell me a support package ... maybe that's a way for them to sell more support packages, I don't know.

Lastly please go back and read all the posts before you make comments like you have above. Your comments were all spoken like a true Marketcircle sales rep. I'm not sure why you think that I shouldn't criticize the actual database design (which is on the desktop BTW, not the iPhone, but you'll find that out when you read the rest of the thread). Not enforcing unique identifiers to be unique at the database level is a horrible design, no matter the intent. And yes, while I can agree that following the rules doesn't necessarily make for a good database design I can say with near certainty that NOT following the rules, especially in matters like this, most certainly *does* make for a bad one.


----------



## Oakbridge (Mar 8, 2005)

mguertin said:


> The problem with the row id's isn't so much that they are setup 100's of numbers apart (and btw, your argument about multiuser makes zero sense as to why they would be a hundred numbers apart) it's the fact that they do not enforce them as keys at the database level, in other words it's easy for what just happened to me to happen to anyone. If they were enforced at the database level then my database wouldn't have been broken in the way it was.
> 
> Their support is atrocious, they have dropped the ball at every step of the game and done nothing but tried to sell me a support package ... maybe that's a way for them to sell more support packages, I don't know.
> 
> Lastly please go back and read all the posts before you make comments like you have above. Your comments were all spoken like a true Marketcircle sales rep. I'm not sure why you think that I shouldn't criticize the actual database design (which is on the desktop BTW, not the iPhone, but you'll find that out when you read the rest of the thread). Not enforcing unique identifiers to be unique at the database level is a horrible design, no matter the intent. And yes, while I can agree that following the rules doesn't necessarily make for a good database design I can say with near certainty that NOT following the rules, especially in matters like this, most certainly *does* make for a bad one.


I understand your frustration with the support issues you've been having.

You didn't clarify that you were referring to the database design on the desktop, you pointed to the iPhone in one of the earlier posts as being the most likely source for your problems.

There are many reasons why they are not enforced as keys at the database level. Many developers do not trust the database engine for this, they prefer to rely on their code. Just a personal choice. Another possible reason could be that records have the potential to be created on both the computer platform and the iOS platform, and the database engines on both may not enforce keys in the same manner, therefore it makes sense from a design perspective to ensure consistency that they are handled in the code. Again I don't know the reason behind the design, neither do you. Only the design and development team at Marketcircle know the reason. The fact that they have chosen to use a method that you disagree with does not make it wrong. 

As for creating keys in increments of 100 it's a simple programming method that I've seen used in many different systems for many different reasons going back to dBase days. With a synchronized system, it creates unique ID's even for multiple users or for a single user creating records on multiple devices. For the first user or device, the keys start at 100 and go up in increments of 100 (200, 300, etc). The second offline user or device in the same system starts at 101 and goes up in increments of 100 (201, 301, etc.), the third user starts at 103 (203, 303, etc.). This guarantees that in systems where there is offline or synchronized databases, you avoid duplicating keys. I'm not sure if this is in fact the reason why Billings is using it, this is just one example of why it can be used. 

I'm still curious to know what you did to gain this knowledge about the database design that Marketcircle is using. Care to explain?


----------



## hayesk (Mar 5, 2000)

Oakbridge said:


> As for creating keys in increments of 100 it's a simple programming method that I've seen used in many different systems for many different reasons going back to dBase days. With a synchronized system, it creates unique ID's even for multiple users or for a single user creating records on multiple devices. For the first user or device, the keys start at 100 and go up in increments of 100 (200, 300, etc). The second offline user or device in the same system starts at 101 and goes up in increments of 100 (201, 301, etc.), the third user starts at 103 (203, 303, etc.).


Even entry level university database classes teach you why relying on row ids as your unique keys is a terrible idea, if you can't figure it out on your own. It has two major problems.

1. What if you want to add another client but you already have 100 clients?
2. What if you want to merge data from another installation? With row ids, you can not to this. There will be conflicts. It's not enough to simply not support merging. Suppose your hard drive crashes, but you need to be back up and running right away. You want to install on another machine while waiting for your other data to be restored, and merge the restored data later. You will often have conflicts.

Row ids are for the database manager to manage its own instance of the database. It shouldn't be used for a unique key for user data.

The solution is to use UUIDs or a similar id system that is guaranteed to be unique across different instances of the database.


----------



## Guest (Nov 18, 2011)

Oakbridge said:


> I'm still curious to know what you did to gain this knowledge about the database design that Marketcircle is using. Care to explain?


The database is freely browsable, and editable for that matter, with anything that will let you manipulate sqlite databases and it lives in the (I think, am not currently at the machine running it) ~/LibraryApplication Support/Billings/Database folder.

It took me about 5 minutes to reverse engineer it enough to fix my problem (that they claim was unfixable) and during that time I didn't like what I saw. There are many ways to do things, but after looking at it I would not approve this approach for anything that I build. I will leave it at that and move on.


----------



## Guest (Nov 18, 2011)

hayesk said:


> The solution is to use UUIDs or a similar id system that is guaranteed to be unique across different instances of the database.


They are using UUIDs for clients (local app, other desktop apps, iOS, etc) but from my brief look that was about it for real unique identifiers anywhere. The 100 spaced potentially non-unique row ids were for time slips within projects (and were the root of my issue).


----------

