Re: Long running reports to disk intermittently disrupted and fail

> Le 20 avr. 2020 à 08:06, Chip Scheide via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > :) > that was my point. > > if the file is created on the client, > new record > document to [table]blob > save record Hi Chip, the problem with that technique is that [table] will probably inflate/def

Re: Long running reports to disk intermittently disrupted and fail

:) that was my point. if the file is created on the client, new record document to [table]blob save record blob is now on the server. deamon running on server looks for new records in [table] when found, it extracts it/them. alternatively after saving the new record on the client execute on ser

Re: Long running reports to disk intermittently disrupted and fail

Chip Scheide: >> Now I create the document as before, do a document to blob on the >> client and call an "execute on server"-method that sends the blob to >> the server where it gets written to the directory with blob to > why not just save the blob in a (temporary) record? > the blob is auto

Re: Re: Long running reports to disk intermittently disrupted and fail

why not just save the blob in a (temporary) record? the blob is auto transmitted to the server via 4D. and you can then (on the server) do a blob to document if necessary > Now I create the document as before, do a document to blob on the > client and call an "execute on server"-method that send

Re: Long running reports to disk intermittently disrupted and fail

On Apr 17, 2020, at 12:15 PM, John J Foster wrote: Hey Kirk and Miyako, I like the idea of having a copy at months end and then moving it. This client is quite picky about what I can do and what I can’t. Been working with them since 1994-1995 I think. Anyway thanks for the ideas. Appreciat

Re: Long running reports to disk intermittently disrupted and fail

Hey Arnaud, No worries not on a MacOS. John… > Unfortunately on macOS it's not enough, I sometimes have the shared volume > when I ask "are you here", a while after it's gone. I use an applescript that > is called each time 4D sees a volume is gone to mount it, but same problem > can occur.

Re: Re: Long running reports to disk intermittently disrupted and fail

Arnaud de Montard: > Unfortunately on macOS it's not enough, I sometimes have the shared volume > when I ask "are you here", a while after it's gone. I use an applescript that > is called each time 4D sees a volume is gone to mount it, but same problem > can occur. I feel like fighting with win

Re: Long running reports to disk intermittently disrupted and fail

> Le 16 avr. 2020 à 22:33, John J Foster via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Hi Arnaud, > > Yes that path would have to tested and if not found then a report or email > sent alerting them. Unfortunately on macOS it's not enough, I sometimes have the shared volume when I ask "a

Re: Long running reports to disk intermittently disrupted and fail

also, don't forget to compress the BLOB. text files compact pretty well. > On Apr 17, 2020, at 7:17, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> > wrote: > Once the file is created you can blob it up and move it back to the client. > It will still befaster I bet. ***

Re: Long running reports to disk intermittently disrupted and fail

John, On Thu, Apr 16, 2020 at 1:39 PM John J Foster via 4D_Tech < 4d_tech@lists.4d.com> wrote: > Right now there’s a specific computer where these reports are run from at > the end of each month. And yes they need to run at the end of the last day > of the month and before any new data has been ad

Re: Long running reports to disk intermittently disrupted and fail

Hi Randy, Good to know. Since I don’t have access, remote or otherwise, I’ll have to teach the client how to use that. Anyway, it doe sound like it’s doable. And worst case the document is still created it just might not be moved if the drive cannot be found for there’s an error during the at

Re: Long running reports to disk intermittently disrupted and fail

John, > On Apr 16, 2020, at 3:47 PM, John J Foster via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > Agreed! > > I will try and change them if I can figure how to test the Server to see if > it can see the network drive. > > I would imagine that it can but never assume… You should be able to,

Re: Long running reports to disk intermittently disrupted and fail

Hey Randy, Agreed! I will try and change them if I can figure how to test the Server to see if it can see the network drive. I would imagine that it can but never assume… I’ll see if I can find out. Appreciate, John… > On Apr 16, 2020, at 12:00 PM, 4d_tech-requ...@lists.4d.com wrote: > >>

Re: Long running reports to disk intermittently disrupted and fail

Hey Jeff, Been a while since I had to use Process Monitor as part of a debugging process. I don't have access to the Windows Sever that runs our 4D Server App. But I could ask my contact what the setup is. I pretty much have to try and debug with the non-IT folks. Anyway good idea. Thanks, Jo

Re: Long running reports to disk intermittently disrupted and fail

Hey Kirk, > I agree with Jim Ditto! Yes I have been exploring the idea of moving the code to run on the Server. It’s easy s I only need to set a property. But then I still need the Server to be able to see the paths to where the text files need to be moved to. I have no access to their Server

Re: Long running reports to disk intermittently disrupted and fail

Hi Arnaud, Yes that path would have to tested and if not found then a report or email sent alerting them. John… >> Le 15 avr. 2020 à 23:35, John J Foster via 4D_Tech <4d_tech@lists.4d.com >> > a écrit : >> >> I do think writing the file locally and then moving it

Re: Long running reports to disk intermittently disrupted and fail

> On Apr 16, 2020, at 8:41 AM, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > John, > > Better yet - re-write the file generation to run on the server. In my > experience when a report like that takes so long to run it's due to moving > lots of data back and forth. Move the code th

Re: Long running reports to disk intermittently disrupted and fail

John, I agree with Jim: separate the creation of the file from moving the file to the network. A lot has changed in the last 20 years or so with the way network access is managed and old code like this that looks at a network address as equivalent to a local disk are problematic. We ran into this o

Re: Long running reports to disk intermittently disrupted and fail

> Le 15 avr. 2020 à 23:35, John J Foster via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > I do think writing the file locally and then moving it makes a lot of sense. > Right now they choose the path to save files to but it would b easy enough to > create it locally move doc into the path.

Re: Long running reports to disk intermittently disrupted and fail

Hey Jim, > If your machine is on an SSD… That makes sense to my very simple mind! I don’t think in all my years of 4D dating back to beta Silver Surfer days I have ever needed a routine where buffering using a BLOB was required. That’s amazing! Anyway... Thanks again for your advice and for

Re: Long running reports to disk intermittently disrupted and fail

On Apr 15, 2020, at 4:35 PM, John J Foster via 4D_Tech <4d_tech@lists.4d.com> wrote: > > I do believe that creating it locally and moving to the network drive can be > more efficient. I’m not sure how much speed different there would be. > >> using TEXT TO BLOB with the offset parameter > > I’

Re: Long running reports to disk intermittently disrupted and fail

Hey Neil, That’s interesting. This client, although in 4D v17.2 (yes unicode), hates upgrading. So I will have to code in v17 efficiency. I think I’d be find with the slowness if I can figure out why the routine either stalls or timeout or suddenly cannot find the disk. I do think writing the

Re: Long running reports to disk intermittently disrupted and fail

> The fastest way to build the output is probably with a pre-sized blob, and > using TEXT TO BLOB with the offset parameter. Pushing elements into a > collection and then using collection.join() is also pretty fast, but again > you’d have to test to see how large a text variable can actually be,

Re: Long running reports to disk intermittently disrupted and fail

Hey Jim, Yea you could be right! I do believe that creating it locally and moving to the network drive can be more efficient. I’m not sure how much speed different there would be. > using TEXT TO BLOB with the offset parameter I’m investigating this command and seeing if I can understand how t

Re: Long running reports to disk intermittently disrupted and fail

On Apr 15, 2020, at 2:20 PM, John J Foster via 4D_Tech <4d_tech@lists.4d.com> wrote: > > 4D v17.2 64bit Windows > Windows 10 Pro > > We have some reports that are run in a batch overnight. Have to because they > take that long to run all of them. Anyway, since we’ve upgraded from Windows > 7 t

Long running reports to disk intermittently disrupted and fail

Hi All, Sorry for the resend … 4D v17.2 64bit Windows Windows 10 Pro We have some reports that are run in a batch overnight. Have to because they take that long to run all of them. Anyway, since we’ve upgraded from Windows 7 to Windows 10 there have been I’m guessing timeouts on some of these

Long running reports to disk intermittently disrupted and fail

Hey All, When it rains it pours… 4D v17.2 64bit Windows Windows 10 Pro We have some reports that are run in a batch overnight. Have to because they take that long to run all of them. Anyway, since we’ve upgraded from Windows 7 to Windows 10 there have been I’m guessing timeouts on some of thes