Is it a problem to fetch too many rows in a download_delete cursor ?

[Former Member]

Hi,

I have a rather complex download_delete cursor. It contains a lot of SQL joins and performance isn't optimal on the consolidated db. I would like to simplify this, but this would result in fetching records (for deletion) that have never been downloaded to the remote database. Is this a problem for Mobilink?

Thanks !

[VolkerBarth]

Just as a side-effect: Might that include rows with primary keys that could have been added to the remote database in the meantime (say between upload and download)?

[Former Member]

These are rows that are only added via the consolidated database. If this is what you mean by your question...?

[VolkerBarth]

If this is what you mean by your question...?

Yes, I think so. I wanted to make sure you would not accidentally delete rows on the remote that are contained in the consolidated and that are not (to the consolidated's knowledge) part of the remote's contents but might have been inserted in the remote in the interim - but I see this would usually require some kind of "PK re-use" which is generally a no-go in ML setups AFAIK... - So I guess please disregard my comments...

[Former Member]

no prob. I Always go for Guids when I can.

[regdomaratzki · Accepted solution]

This will create more data in the download stream (since the primary key of the rows that don't exist will also be sent) and will also result in the MobiLink client executing a "delete from table where pkey=X" for rows that don't exist at the remote when it applies the download stream. This means the time to write the download stream to the wire will be longer, and the time to apply the download stream at the remote will also be longer.

You should test whether the performance gains from the re-write of the download_delete_cursor are worth the extra time needed to write more data to the stream and apply the download.

[Former Member · Accepted solution]

Thanks for your advice, will think about this when testing. I'm assuming that mobilink atleast won't throw an exception about "records to delete" but aren't there on the remote.

[Breck_Carter · Accepted solution]

Since dbmlsync silently deletes rows rather than throwing a hissy fit exception for a foreign key violation, it's hard to believe that it would object to an operation that returns a warning (SQLCODE 100 Row not found)...

...but it's still worth testing.

[Breck_Carter · Accepted solution]

@Reg: Excellent answer, just missing one teeny thing... an answer to the question that was asked ( snork 🙂

[Former Member · Accepted solution]

I've tested this today and it looks like it's not giving any problems.

[Breck_Carter · Accepted solution]

> not giving any problems

Thanks for posting that! ( once again The Watcom Rule applies 🙂

[VolkerBarth · Accepted solution]

Now you have to tell us who is who...?

[Former Member · Accepted solution]

I actually clicked a few times on Brecks profile to check if the guy on the left was not him.

[Breck_Carter · Accepted solution]

This is all I know...

Unbundling Computing at The University of Waterloo

This in 1984 commemorates the sale of WATSOFT Products, by UW, to WATCOM. After the purchase of WATSOFT, the fortunes of WATCOM developed an international market. A little over ten years later, the company was acquired by the US-based firm Powersoft for $48 million. A year later Powersoft was purchased by Sybase of California, the world's sixth largest computer software company

[Breck_Carter · Accepted solution]

If I looked like the guy on the left in 1984 I'd be long dead today... fortunately for me I looked a lot more like the guy on the right but with big hair and disco pants 🙂

I did have one of those VGA monitors, though... text in 16 (sixteen!) colors! Magenta! Cyan! "We LOVE pink!"

[VolkerBarth · Accepted solution]

Wow, VGA in 1984 in colors - I had to be happy with EGA or Hercules monochrome (but hey, amber on black!) in 1990...

[VolkerBarth · Accepted solution]

Ah, so that's a question for Jack Schueler, apparently.

[Breck_Carter · Accepted solution]

You're right, it wasn't VGA... it was the IBM PC color monitor that was available for (I think) about C$1000 in 1981.