I*****N
发帖数: 497 | 1 而是系统更新的日期。看看这个已经批了的485.
lin1490347142。 My case tracker 显示rd： 2/28/2014.
再到uscis 网站上看看其他相近号的状态，不可能是2/28附近。
所以你用rd查自己的rd有人485已经批了，但是不代表已经批到那个日期了。一般是批
一个礼拜以前的rd。 |
a9
发帖数: 21638 | 2 my case tracker也没有特殊的接口去拿数据，也是抓页面吧？
如果抓晚了，前面的状态就抓不到了。所以我觉得抓的密度很重要。
相信不管是这个网站的管理员，还是uscis都不希望这种高密度的抓取，
所以这个数据也就仅供参考。不要那么较真。
【在 I*****N 的大作中提到】
: 而是系统更新的日期。看看这个已经批了的485.
: lin1490347142。 My case tracker 显示rd： 2/28/2014.
: 再到uscis 网站上看看其他相近号的状态，不可能是2/28附近。
: 所以你用rd查自己的rd有人485已经批了，但是不代表已经批到那个日期了。一般是批
: 一个礼拜以前的rd。
|
F*********u
发帖数: 12190 | 3 增加密度需要添加服务器，需要大家捐款~
【在 a9 的大作中提到】
: my case tracker也没有特殊的接口去拿数据，也是抓页面吧？
: 如果抓晚了，前面的状态就抓不到了。所以我觉得抓的密度很重要。
: 相信不管是这个网站的管理员，还是uscis都不希望这种高密度的抓取，
: 所以这个数据也就仅供参考。不要那么较真。
|
b********g
发帖数: 94 | 4 参考我刚在另外一个帖子的回复
我来回答一下有关RD的问题，大概有70%左右的RD是准确的，如果tracker能扫描到第一
个Acceptance的话，RD基本上是准的，如果是Initial Review的话，有的是准确的RD，
有的不是。如果tracker第一次扫描到的不是Acceptance的话，就要用receipt number
和附近的号比较，推算RD，推算的大概有30%的号。
MyCase analysis已经恢复了，前两天R升级到3.1，有些package需要rebuilt.
To FranklinDou，非常感谢你的提议
To a9，的确是密度的问题，但是不能开太多的服务器，只有在有限的线程优化每个
receipt抓取的间隔时间。。。 |
F*********u
发帖数: 12190 | 5 这个从附近的号推断RD准么？
我自己的RD比较新，所以周围的号状态基本都是received on (date)
有些比我靠前一点的号RD反倒比我晚个4、5天
number
【在 b********g 的大作中提到】
: 参考我刚在另外一个帖子的回复
: 我来回答一下有关RD的问题，大概有70%左右的RD是准确的，如果tracker能扫描到第一
: 个Acceptance的话，RD基本上是准的，如果是Initial Review的话，有的是准确的RD，
: 有的不是。如果tracker第一次扫描到的不是Acceptance的话，就要用receipt number
: 和附近的号比较，推算RD，推算的大概有30%的号。
: MyCase analysis已经恢复了，前两天R升级到3.1，有些package需要rebuilt.
: To FranklinDou，非常感谢你的提议
: To a9，的确是密度的问题，但是不能开太多的服务器，只有在有限的线程优化每个
: receipt抓取的间隔时间。。。
|
H******i
发帖数: 4704 | 6 提醒bigfacepig大牛：我接到USCIS内部线报，USCIS正在酝酿对 my case status 进行
整改，要搞一个 ＂a complete new architecture for our case status on line＂，
项目已经启动，但是什么时候进入production不知道。希望不会影响mycasetracker.
number
【在 b********g 的大作中提到】
: 参考我刚在另外一个帖子的回复
: 我来回答一下有关RD的问题，大概有70%左右的RD是准确的，如果tracker能扫描到第一
: 个Acceptance的话，RD基本上是准的，如果是Initial Review的话，有的是准确的RD，
: 有的不是。如果tracker第一次扫描到的不是Acceptance的话，就要用receipt number
: 和附近的号比较，推算RD，推算的大概有30%的号。
: MyCase analysis已经恢复了，前两天R升级到3.1，有些package需要rebuilt.
: To FranklinDou，非常感谢你的提议
: To a9，的确是密度的问题，但是不能开太多的服务器，只有在有限的线程优化每个
: receipt抓取的间隔时间。。。
|
p*********s
发帖数: 1952 | 7 是你做的？
【在 F*********u 的大作中提到】
: 增加密度需要添加服务器，需要大家捐款~
|
F*********u
发帖数: 12190 | 8 不是啊，是大脸猪大侠吧
我只是自带干粮帮忙吆喝一下
【在 p*********s 的大作中提到】
: 是你做的？
|
p*********s
发帖数: 1952 | 9 这个附近的号推断有可能不对，设计有问题，为啥不每个case number建立记录呢？酱紫
就可以知道每个case的timeline了，而且不用track没用的case number，只要track 48
5的case number就好了，别的都不那么重要，这样可以省掉不小数据库的负担。
number
【在 b********g 的大作中提到】
: 参考我刚在另外一个帖子的回复
: 我来回答一下有关RD的问题，大概有70%左右的RD是准确的，如果tracker能扫描到第一
: 个Acceptance的话，RD基本上是准的，如果是Initial Review的话，有的是准确的RD，
: 有的不是。如果tracker第一次扫描到的不是Acceptance的话，就要用receipt number
: 和附近的号比较，推算RD，推算的大概有30%的号。
: MyCase analysis已经恢复了，前两天R升级到3.1，有些package需要rebuilt.
: To FranklinDou，非常感谢你的提议
: To a9，的确是密度的问题，但是不能开太多的服务器，只有在有限的线程优化每个
: receipt抓取的间隔时间。。。
|
a9
发帖数: 21638 | 10 你加大了密度，uscis不干了，给封了怎么办。
【在 F*********u 的大作中提到】
: 增加密度需要添加服务器，需要大家捐款~
|
