Is there a way to trap an error generated in another app that is controlled
via automation? I have an Access 2000 app that opens Word 2000 and proceeds
to open a series of documents and, in each document, parse the contents and
write it to an Access table (the Access app, after opening Word, runs a
macro within Word which parses and writes to the Access app via DAO).
Occasionally we get an error from Word (such as "document is locked for
editing" or other), which hangs the process. The process is an overnight
one, so, obviously, if it hangs from a Word error message.
Is there a way to trap these error messages generated by Word and just move
onto the next document?
Thanks,
Neil 21 2504
Why not move the Word Macro to Access VBA code?
Because it was hideously slow when I did it that way. When the Word document
was sent through the pipe to Access for Access to parse, it was very slow.
When I moved the code to a Word macro, allow Word to parse it itself without
sending to Access, and then have Word write to an Access table, it was much
faster (though it still takes a fair amount of time).
But I suppose I could open the Word doc from Access and then just use the
Word macro to parse it. That might work.
Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com... Why not move the Word Macro to Access VBA code?
That's a pretty common way to do it. Write the Macro in Word, but call it via
Access automation, and trap errors returned from the call.
On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote: Because it was hideously slow when I did it that way. When the Word document was sent through the pipe to Access for Access to parse, it was very slow. When I moved the code to a Word macro, allow Word to parse it itself without sending to Access, and then have Word write to an Access table, it was much faster (though it still takes a fair amount of time).
But I suppose I could open the Word doc from Access and then just use the Word macro to parse it. That might work.
Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message news:11**********************@o13g2000cwo.googleg roups.com... Why not move the Word Macro to Access VBA code?
No, that's not what I'm saying. I'm saying that I *already* call the macro
via Automation from Access, but don't get error messages in Access to trap.
In one particular example, if the file's already open, a dialog box appears
in Word, "File is locked for editing" or something like that, which screws
up the whole process. As I note below, perhaps if I move the file open
portion of the code to Access, then I'll be able to trap an error (right now
it's in the macro).
But it seems that when one runs a macro via automation, that any errors that
happen through the macro execution are not trappable by the calling
application (in this case, Access). Or do you know of a way of doing that?
Thanks,
Neil
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:la********************************@4ax.com... That's a pretty common way to do it. Write the Macro in Word, but call it via Access automation, and trap errors returned from the call.
On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote:
Because it was hideously slow when I did it that way. When the Word document was sent through the pipe to Access for Access to parse, it was very slow. When I moved the code to a Word macro, allow Word to parse it itself without sending to Access, and then have Word write to an Access table, it was much faster (though it still takes a fair amount of time).
But I suppose I could open the Word doc from Access and then just use the Word macro to parse it. That might work.
Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message news:11**********************@o13g2000cwo.google groups.com... Why not move the Word Macro to Access VBA code?
Hi Neil,
It sounds as if you need to beef up the error trapping in the Word
macro.
For instance, before trying to open a document in Word, try to open it
as a binary file in a mode that will lock it. If that fails, you'll know
that Word won't be able to open it either, and you can either skip the
file or try making a copy of it and opening that.
If you're not familiar with this article, it's worth reading, as are
some of the articles it links to:
Considerations for Server-Side Automation of Office http://support.microsoft.com/?id=257757
On Mon, 09 May 2005 09:16:29 GMT, "Neil" <no****@nospam.net> wrote: No, that's not what I'm saying. I'm saying that I *already* call the macro via Automation from Access, but don't get error messages in Access to trap.
In one particular example, if the file's already open, a dialog box appears in Word, "File is locked for editing" or something like that, which screws up the whole process. As I note below, perhaps if I move the file open portion of the code to Access, then I'll be able to trap an error (right now it's in the macro).
But it seems that when one runs a macro via automation, that any errors that happen through the macro execution are not trappable by the calling application (in this case, Access). Or do you know of a way of doing that?
Thanks,
Neil
"Steve Jorgensen" <no****@nospam.nospam> wrote in message news:la********************************@4ax.com.. . That's a pretty common way to do it. Write the Macro in Word, but call it via Access automation, and trap errors returned from the call.
On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote:
Because it was hideously slow when I did it that way. When the Word document was sent through the pipe to Access for Access to parse, it was very slow. When I moved the code to a Word macro, allow Word to parse it itself without sending to Access, and then have Word write to an Access table, it was much faster (though it still takes a fair amount of time).
But I suppose I could open the Word doc from Access and then just use the Word macro to parse it. That might work.
Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message news:11**********************@o13g2000cwo.googl egroups.com... Why not move the Word Macro to Access VBA code?
--
John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
"hideously slow"?!? Then you're doing something wrong, more then just
error trapping.
Usually, it'll go faster.
On 9 May 2005 16:04:52 -0700, "Chuck Grimsby" <c.*******@worldnet.att.net>
wrote: "hideously slow"?!? Then you're doing something wrong, more then just error trapping.
Usually, it'll go faster.
That's not my experience. Every COM call that passes across an application
barrier has a lot of overhead. If you're running a loop in Access, making
calls to libraries in Word, there's a real performance hit. The documentation
even says so, and recommends ways to mitigate the problem like calling
functions that take array parameters rather than making individual calls in a
loop.
That's a good idea about the Word macro and checking if the file's open. I
was hoping there was a way to have the calling app actually get any errors
that the automated app experiences. But I guess not.
N
"John Nurick" <j.*************@dial.pipex.com> wrote in message
news:7m********************************@4ax.com... Hi Neil,
It sounds as if you need to beef up the error trapping in the Word macro.
For instance, before trying to open a document in Word, try to open it as a binary file in a mode that will lock it. If that fails, you'll know that Word won't be able to open it either, and you can either skip the file or try making a copy of it and opening that.
If you're not familiar with this article, it's worth reading, as are some of the articles it links to: Considerations for Server-Side Automation of Office http://support.microsoft.com/?id=257757
On Mon, 09 May 2005 09:16:29 GMT, "Neil" <no****@nospam.net> wrote:
No, that's not what I'm saying. I'm saying that I *already* call the macro via Automation from Access, but don't get error messages in Access to trap.
In one particular example, if the file's already open, a dialog box appears in Word, "File is locked for editing" or something like that, which screws up the whole process. As I note below, perhaps if I move the file open portion of the code to Access, then I'll be able to trap an error (right now it's in the macro).
But it seems that when one runs a macro via automation, that any errors that happen through the macro execution are not trappable by the calling application (in this case, Access). Or do you know of a way of doing that?
Thanks,
Neil
"Steve Jorgensen" <no****@nospam.nospam> wrote in message news:la********************************@4ax.com. .. That's a pretty common way to do it. Write the Macro in Word, but call it via Access automation, and trap errors returned from the call.
On Mon, 09 May 2005 04:42:36 GMT, "Neil" <no****@nospam.net> wrote:
Because it was hideously slow when I did it that way. When the Word document was sent through the pipe to Access for Access to parse, it was very slow. When I moved the code to a Word macro, allow Word to parse it itself without sending to Access, and then have Word write to an Access table, it was much faster (though it still takes a fair amount of time).
But I suppose I could open the Word doc from Access and then just use the Word macro to parse it. That might work.
Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message news:11**********************@o13g2000cwo.goog legroups.com... > Why not move the Word Macro to Access VBA code? >
-- John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
What will go faster? You haven't seen my code, so how do you know how fast
it should go?
Basically the code goes through the Word document one character at a time
and writes strings of characters to a table record when there's a change in
formatting. When Access opened the Word document and then, via the object
variable, parsed the document, looking at each character, it was very slow.
When the process was moved to a Word macro that was called from Access, it
was much faster.
I mean, sure, opening a doc and maybe getting the text is pretty quick. But
this had to look at each character's formatting, etc. Each process of
getting the character's information took x amount of time. When added
together for an entire document, and then multiplied over a couple thousand
documents, it was very slow. Much performance gain when done on the Word
side.
Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com... "hideously slow"?!? Then you're doing something wrong, more then just error trapping.
Usually, it'll go faster.
I agree with what you wrote. The act of calling the Word doc, over and over,
once for each character, was hideously slow.
I would have preferred to keep everything Access-side, but I don't see how I
could accomplish the parsing of the document without a loop, having to look
at each character's formatting.
Neil
"Steve Jorgensen" <no****@nospam.nospam> wrote in message
news:ep********************************@4ax.com... On 9 May 2005 16:04:52 -0700, "Chuck Grimsby" <c.*******@worldnet.att.net> wrote:
"hideously slow"?!? Then you're doing something wrong, more then just error trapping.
Usually, it'll go faster.
That's not my experience. Every COM call that passes across an application barrier has a lot of overhead. If you're running a loop in Access, making calls to libraries in Word, there's a real performance hit. The documentation even says so, and recommends ways to mitigate the problem like calling functions that take array parameters rather than making individual calls in a loop.
"Neil" <no****@nospam.net> wrote in
news:rG**************@newsread1.news.pas.earthlink .net: Basically the code goes through the Word document one character at a time and writes strings of characters to a table record when there's a change in formatting.
Perhaps, we should see your code. If you are examining a file byte by byte
then one assumes there is some reason for opening it with a Word Macro, or
processing it with a Word Macro.
If the string of characters is converted to a byte array there might be
considerable improvement in performance.
If the file is opened with low-level file procedures there might be might be
considerable improvement in performance.
--
Lyle
On Tue, 10 May 2005 05:31:03 GMT, "Neil" <no****@nospam.net> wrote: Basically the code goes through the Word document one character at a time and writes strings of characters to a table record when there's a change in formatting. When Access opened the Word document and then, via the object variable, parsed the document, looking at each character, it was very slow. When the process was moved to a Word macro that was called from Access, it was much faster.
If that's what you're having to do, Neil, the thought of saving the
document as XML and then using an XML parser (or maybe just a regex) to
find characters between certain tags sounds pretty appealing.
--
John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
Right. But the point is that I need to see the formatting of the characters
and place identically formatted characters in the same parsings record.
So, for example, If the document had "My dog" where "dog" was in bold, I'd
end up with "My " in one entry (with values specifying point size, font
name, font weight, etc.) and "dog" in another entry (with same values,
except it would be noted as bold).
In order to accomplish that I need to be able to see the formatting, which
can only be (as far as I can see) done through Word automation. If I open it
with low-level file procedures or store in a byte array, I'll lose the
formatting.
Or am I missing something?
"Lyle Fairfield" <Lo******@FFDBA.Com> wrote in message
news:Xn*******************@216.221.81.119... "Neil" <no****@nospam.net> wrote in news:rG**************@newsread1.news.pas.earthlink .net:
Basically the code goes through the Word document one character at a time and writes strings of characters to a table record when there's a change in formatting.
Perhaps, we should see your code. If you are examining a file byte by byte then one assumes there is some reason for opening it with a Word Macro, or processing it with a Word Macro.
If the string of characters is converted to a byte array there might be considerable improvement in performance.
If the file is opened with low-level file procedures there might be might be considerable improvement in performance.
-- Lyle
Would I be able to read the document in Access directly via an add-in, or
how would I read the documents?
"John Nurick" <j.*************@dial.pipex.com> wrote in message
news:m3********************************@4ax.com... On Tue, 10 May 2005 05:31:03 GMT, "Neil" <no****@nospam.net> wrote:
Basically the code goes through the Word document one character at a time and writes strings of characters to a table record when there's a change in formatting. When Access opened the Word document and then, via the object variable, parsed the document, looking at each character, it was very slow. When the process was moved to a Word macro that was called from Access, it was much faster.
If that's what you're having to do, Neil, the thought of saving the document as XML and then using an XML parser (or maybe just a regex) to find characters between certain tags sounds pretty appealing.
-- John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
You're right, I haven't seen you code, nor have you seen mine!
I have a routine I use to convert a Word docuemnt to an HTML file,
which I prefer to use, since I *really* dislike what Word does when you
save a file as an HTML document. Nearly the world's ugliest HTML code,
as far as I'm concerned. But then again... it's trying to be all
things for all things, and the result is probably the best that could
be come up with given those circumstances.
Anyways, it's been a long time since I timed my code, so I just did.
Just under a minute to convert a Word document (with several tables
embedded, but mostly text and a few pictures) to an HTML page. The
word document says it was 36 pages if printed. I haven't had a printer
hooked up to my system from over a decade, so who knows how accurate
that count is.
The code "cheats" a bit by looking at each Word paragraph to determine
if there are any changes to the "standard" font. Just FYI, I guess,
but if you look at each font property, Word will tell you if the
property is the same all the way through the paragraph. The property
returns 0 or -1 if it's the same all the way through the paragraph, if
not, then it returns something that's not 0 or -1. (usually 999999.)
When that's detected, I switch to looking at each word in the
paragraph, doing the same thing with the font properies, and if it
doesn't come back 0 or -1, then it's time to look at each character.
Sure, I suppose I could of looked at each charater from the start, but
why? My goal was mass-processing of word documents to HTML pages, so
the fact that one character was the same as the last didn't really
matter to me, as long as it was the same though the whole paragraph
(which, with the documents I tend to deal with is more often the case
then not. Your milage, as always, may vary.).
Now, mind you, I'm doing this all from Access, using late binding to
Word, since I never know what version my client will be using. But
feel free to do whatever you feel you need to do to accomplish your
goal.
That's an interesting concept. I'm not sure I follow with how you determine
if a font is the same all the way through a paragraph. Perhaps you could
elaborate.
FWIW, I look at font name, font size, font color, bold, italic, and
underline (though, in reality, bold, italic, and underline are really all
that's needed).
Neil
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com... You're right, I haven't seen you code, nor have you seen mine!
I have a routine I use to convert a Word docuemnt to an HTML file, which I prefer to use, since I *really* dislike what Word does when you save a file as an HTML document. Nearly the world's ugliest HTML code, as far as I'm concerned. But then again... it's trying to be all things for all things, and the result is probably the best that could be come up with given those circumstances.
Anyways, it's been a long time since I timed my code, so I just did. Just under a minute to convert a Word document (with several tables embedded, but mostly text and a few pictures) to an HTML page. The word document says it was 36 pages if printed. I haven't had a printer hooked up to my system from over a decade, so who knows how accurate that count is.
The code "cheats" a bit by looking at each Word paragraph to determine if there are any changes to the "standard" font. Just FYI, I guess, but if you look at each font property, Word will tell you if the property is the same all the way through the paragraph. The property returns 0 or -1 if it's the same all the way through the paragraph, if not, then it returns something that's not 0 or -1. (usually 999999.) When that's detected, I switch to looking at each word in the paragraph, doing the same thing with the font properies, and if it doesn't come back 0 or -1, then it's time to look at each character.
Sure, I suppose I could of looked at each charater from the start, but why? My goal was mass-processing of word documents to HTML pages, so the fact that one character was the same as the last didn't really matter to me, as long as it was the same though the whole paragraph (which, with the documents I tend to deal with is more often the case then not. Your milage, as always, may vary.).
Now, mind you, I'm doing this all from Access, using late binding to Word, since I never know what version my client will be using. But feel free to do whatever you feel you need to do to accomplish your goal.
As previously mentioned, "if you look at each font property, Word will
tell you if the property is the same all the way through the paragraph.
The property returns 0 or -1 if it's the same all the way through the
paragraph, if not, then it returns something that's not 0 or -1.
(usually 999999.) "
Additional hints:
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Form attedText.Font.Bold
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).FormattedText.Font.Italic
ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).Characters(lngC).FormattedText.Font.Color
Oh, and remember the 0 = False, -1 = True.
It occured to me, after my post, that this code was written for Word97,
and that since that version things might have changed, but I just
checked and it seems to work fine in Word 2003, although I didn't
bother doing any sort of a time test, I just confirmed it works.
I wasn't clear on what was being referred to when you said, "if you look at
each font property." But I see now that you're referring to the font
property of each paragraph. That's a strange and interesting concept, being
able to see if the font changes in the paragraph. Thanks for the tip.
"Chuck Grimsby" <c.*******@worldnet.att.net> wrote in message
news:11**********************@g44g2000cwa.googlegr oups.com... As previously mentioned, "if you look at each font property, Word will tell you if the property is the same all the way through the paragraph. The property returns 0 or -1 if it's the same all the way through the paragraph, if not, then it returns something that's not 0 or -1. (usually 999999.) "
Additional hints: ObjWord.ActiveDocument.Paragraphs(lngP).Range.Form attedText.Font.Bold ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).FormattedText.Font.Italic ObjWord.ActiveDocument.Paragraphs(lngP).Range.Word s(lngW).Characters(lngC).FormattedText.Font.Color
Oh, and remember the 0 = False, -1 = True.
It occured to me, after my post, that this code was written for Word97, and that since that version things might have changed, but I just checked and it seems to work fine in Word 2003, although I didn't bother doing any sort of a time test, I just confirmed it works.
I'm not an XML expert, Neil, so I can't give much practical help. An XML
file is just a text file so it can be read in any number of ways,
although usually it's simplest to use an XML parser. As far as I know
Access 2003's XML capabilities aren't flexible enough for this and it
would be necessary to get some sort of add-in or library.
I'd hoped that you'd be able to rely on the fact that all the formatting
in an XML document is done with tags enclosed in <angle brackets>, while
the text is enclosed by the tags, e.g.
<tag>this is the text.</tag>
Hence any change in formatting is marked by a tag.
The complication is that when Word saves a document as XML it also uses
tags for many things that don't amount to a change in formatting in the
ordinary sense of the word, such as smart tags. This means it's not
sufficient just to look for text between tags, it's also (I guess,
though I don't know exactly what you're trying to do) necessary to
ignore tags that don't correspond to changes in formatting.
I hope this gives you enough to decide whether you should investigate
XML in more detail.
On Tue, 10 May 2005 21:15:08 GMT, "Neil" <no****@nospam.net> wrote: Would I be able to read the document in Access directly via an add-in, or how would I read the documents?
"John Nurick" <j.*************@dial.pipex.com> wrote in message news:m3********************************@4ax.com.. . On Tue, 10 May 2005 05:31:03 GMT, "Neil" <no****@nospam.net> wrote:
Basically the code goes through the Word document one character at a time and writes strings of characters to a table record when there's a change in formatting. When Access opened the Word document and then, via the object variable, parsed the document, looking at each character, it was very slow. When the process was moved to a Word macro that was called from Access, it was much faster.
If that's what you're having to do, Neil, the thought of saving the document as XML and then using an XML parser (or maybe just a regex) to find characters between certain tags sounds pretty appealing.
-- John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
--
John Nurick [Microsoft Access MVP]
Please respond in the newgroup and not by email.
<11**********************@o13g2000cwo.googlegroups .com>
<0T*****************@newsread1.news.pas.earthlink. net>
<11**********************@f14g2000cwb.googlegroups .com>
<rG**************@newsread1.news.pas.earthlink.net >
<m3********************************@4ax.com>
<wv**************@newsread2.news.pas.earthlink.net >
Newsgroups: comp.databases.ms-access,microsoft.public.access,microsoft.public.ac cess.interopoledde,microsoft.public.office.develop er.automation,microsoft.public.officedev
NNTP-Posting-Host: 154.196.62.81.cust.bluewin.ch 81.62.196.154
Path: number1.nntp.dca.giganews.com!border1.nntp.dca.gig anews.com!nntp.giganews.com!newshub.sdsu.edu!msrtr ans!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14.phx.gbl
Lines: 1
Xref: number1.nntp.dca.giganews.com comp.databases.ms-access:821053 microsoft.public.access:174437 microsoft.public.access.interopoledde:10079 microsoft.public.office.developer.automation:9855 microsoft.public.officedev:15703
Hi Neil, Would I be able to read the document in Access directly via an add-in, or how would I read the documents?
The documents would be saved as plain text, so theoretically, they could be
opened in Notepad.
This means you could open them in Access same as any other text file and
process them (the old Open and Close commands). That would be one possibility
that's "built into" Office VBA.
Another could be to parse them using MSXML. In either case, though, you'd need
to contend with the WordProcessingML, which could be a real bear, depending on
what you really need to do. Basically the code goes through the Word document one character at a time and writes strings of characters to a table record when there's a change in formatting. When Access opened the Word document and then, via the object variable, parsed the document, looking at each character, it was very slow. When the process was moved to a Word macro that was called from Access, it was much faster.
If that's what you're having to do, Neil, the thought of saving the document as XML and then using an XML parser (or maybe just a regex) to find characters between certain tags sounds pretty appealing.
Cindy Meister
INTER-Solutions, Switzerland http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004) http://www.word.mvps.org
This reply is posted in the Newsgroup; please post any follow question or
reply in the newsgroup and not by e-mail :-)
Thanks for the note, Cindy. I like the idea of being able to open the files
directly via Open; but parsing through the XML doesn't look like fun. :-)
Either way, I'd still have to open Word via automation to save each file as
XML. So it seems that just continuing to parse it in Word via automation
might still be the best way.
"Cindy M -WordMVP-" <C.*********@hispeed.ch> wrote in message
news:VA.0000ace1.00978704@speedy... Hi Neil,
Would I be able to read the document in Access directly via an add-in, or how would I read the documents? The documents would be saved as plain text, so theoretically, they could be opened in Notepad.
This means you could open them in Access same as any other text file and process them (the old Open and Close commands). That would be one possibility that's "built into" Office VBA.
Another could be to parse them using MSXML. In either case, though, you'd need to contend with the WordProcessingML, which could be a real bear, depending on what you really need to do.
>>Basically the code goes through the Word document one character at a >>time >>and writes strings of characters to a table record when there's a >>change >>in >>formatting. When Access opened the Word document and then, via the >>object >>variable, parsed the document, looking at each character, it was very >>slow. >>When the process was moved to a Word macro that was called from Access, >>it >>was much faster. > > If that's what you're having to do, Neil, the thought of saving the > document as XML and then using an XML parser (or maybe just a regex) to > find characters between certain tags sounds pretty appealing. >
Cindy Meister INTER-Solutions, Switzerland http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004) http://www.word.mvps.org
This reply is posted in the Newsgroup; please post any follow question or reply in the newsgroup and not by e-mail :-) This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Spike |
last post by:
Is there a clean way to trap errors in PHP?
In Perl there is eval { <code> } and a special variable that can be
checked to see if the execution of the code was successful or not, and
thus a clean...
|
by: Brian |
last post by:
Hi there,
I am converting a large PL/SQL project into Transact-SQL and have hit
an issue as follows:
I have a PL/SQL procedure that converts a string to a date. The
procedure does not know...
|
by: Walter |
last post by:
Hi,
I have a stored proc StoredProc1 =
{
INSERT INTO Table1
SELECT *
FROM View1
Return @@ERROR
}
StoredProc1 is used in another sp StoredProcMain =
|
by: Eitan |
last post by:
Hello,
I need an example of "Trapping Errors" in ASP (not .net)
Thanks :)
|
by: Avi Kak |
last post by:
Hello:
Suppose I write a function that I want to be called
with ONLY keyword argumnts, how do I raise an
exception should the function get called with
what look like position-specfic arguments?...
|
by: asearle |
last post by:
I am a bit new to Perl and am having trouble trapping errors in script ...
However, I think that it is just simple syntax issues and hope that someone can point me towards a good HOWTO which might...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: af34tf |
last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
| |